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

[Stroller]

On 4 Sep 2009, at 21:49, Alan McKinnon wrote:
> On Friday 04 September 2009 17:23:15 Stroller wrote:
> ...
> 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@××××××××.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.

> 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.