Re: [gentoo-user] {OT} reverse DNS problem?

[Grant <emailgrant@gmail.com>]

>> Every other solution out there has this one little problem that people
>> seem to
>> ignore.
>>
>> Per RFC, if you accept the connection and the mail, you will deliver it.
>> That's what it says. It also says this since days long before spam
>> problems,
>> but still. We all conveniently ignore this if we are talking about what
>> *we*
>> consider spam, and by "we" I mean "everyone who cares to take an interest
>> except the actual recipient".
>>
>> ... Yet we accepted the mail implying that we will deliver it...
>
> I don't think it's necessary to break RFC if you reject based on a bogus
> HELO. The connection is initiated, but you do not get as far as accepting
> the mail.
>
>> Instantly, 85% of the problem goes
>> away, and I have numbers to prove it.
>
> 85% of the problem goes away if you use Spamhaus, and that doesn't require
> you to discard legitimate email.
>
>> And why is a user on a DSL range running a mail server anyway?
>
> Personally, from my own point of view, it's so that I can see clearly that a
> message has been delivered.
>
> EG:
>
> Sep  1 18:42:22 compaq postfix/smtp[6121]: A66A2137D25:
> to=<XXX@yahoo.co.uk>, relay=mx1.mail.eu.yahoo.com[217.12.11.64], delay=2,
> status=sent (250 ok dirdel)
>
> I get complaints ALL the time from my customers, "oh, my brother / mother /
> customer / supplier says they sent me an email and I never received it". The
> only way I can debug this is to send them test messages (sometimes daily)
> and tell them to let me know if they don't arrive.
>
> If a customer comes to you with a log entry that looks like the above,
> referring to your server's hostname & IP, complaining the message was never
> delivered, then you can, reluctantly, look in the problem, grepping for
> A66A2137D25.
>
> If the customer comes to you with a log entry like the above with
> relay=smtp.my-isp.com then your response will be "oh, we probably never got
> the message from your ISP". I presumably can log a support issue with my ISP
> & expect them to come up with the log of the message being delivered to your
> servers, but it's simply easier if I can debug non-deliveries myself.
>
>> The vast
>> overwhelming majority of them are Windows zombies!
>
> Which are easily filtered by checking their HELO resolves to an independent
> domain. Or am I missing something here?
>
> The remainder of those you're inefficiently filtering are Linux enthusiasts
> running Postfix on their Gentoo boxes.

Yeah, I was planning on setting up postfix on my home Gentoo box too.
I guess I could relay through my ISP to avoid delivery problems like
this.

Why hasn't greylisting been mentioned?  I greylist and it ends up
blocking at least 99% of spam in my experience.

- Grant


>> And finally, my mail servers are mine and I make decisions about them, not
>> someone else.
>
> Sure, but you're making unilateral decisions about the validity of emails on
> behalf of your customers. And around here the customer comes first.
>
> If Bob wants to send Alice an email, he shouldn't have to reconfigure his
> email server because Fred, the systems administrator at Alice's ISP, is
> being a knob about things.
>
> You may be the exception, having a narrow pipe and being unable to afford
> the Spamhaus / DNS lookups to filter spambots in efficient ways. Most
> systems administrators using this policy are unable to justify the decision.
>
>> Best policy is to stipulate in the ISP's terms of service that you will
>> not
>> accept inbound mail connections from range you feel you cannot trust and
>> users
>> must use their ISPs mail relay instead.
>
> You certainly won't get me subscribing to your service.
>
> Stroller.