Re: [Exim] AOL - SPF - and EXIM

Top Page
Delete this message
Reply to this message
Author: Exim User's Mailing List
Date:  
To: Tony Finch
CC: Exim User's Mailing List
Subject: Re: [Exim] AOL - SPF - and EXIM
[ On Sunday, June 13, 2004 at 23:42:40 (+0100), Tony Finch wrote: ]
> Subject: Re: [Exim] AOL - SPF - and EXIM
>
> There are a number of reasons for rejecting the RCPT command because of
> problems with HELO or MAIL FROM, instead of rejecting immediately:


s/reasons/excuses/ :-)

> You might apply weaker security restrictions for email to postmaster
> in order to make it possible for people to send problem reports via email;


That will not help any in the end. Even in ISP and corporate
environments it's not really worthwhile to accept "complaints" by e-mail
from people who haven't got enough of a clue to find an un-blocked
system to send mail from. Really. You're going to have to deal with
the less clued via the telephone or FAX anyway so it's best just to get
them started in that direction. (and you really do _not_ want any junk
from anyone so clueless that they can't find your organisation's phone
number through Goolgle or WHOIS! ;-)


> You might want a more complete record of attempts to send email (including
> sender and recipient email addresses) to make it easier to diagnose
> problems accurately;


If so then your requirements are contrary to your policies. Straighten
these things out before digging an even deeper hole! I.e. you'd be
confusing yourself and your users as well as any legitimate remote user
getting rejected! Either set and implement policies to reject unwanted
senders and do it properly, or don't even bother.


> The extra data might be useful for passive analysis of host behaviour, to
> identify spammers or virus infections etc.


No, it's not really.

(maybe from your own local MUAs on your own locally trusted networks,
but we already know we have to deal with those specially anyway)


> I agree that it could be considered to be confusing, but this can be
> mitigated by ensuring that the error messages are useful. Yes, the error
> message may be lost by incompetent software


"incompetent software" is just the tip of the iceberg -- the real
problem is with human language.

You CANNOT assume that the recipient of a DSN containing your reject
message can even begin to read that message let alone understand it.

> A recent example was Outlook reporting the "503 valid RCPT
> command must precede DATA" error rather than the RCPT rejection that would
> have clued in the user.


Since when did "Outlook" become a real mail server!?!?!?! NOT!

MUA client-SMTP/submission implementations are irrelevant in this
discussion.

(and if your policy is to accept SMTP connections from random untrusted
MUAs then you're probably not ever going to be rejecting many, if any,
connections because of HELO problems!)

--
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>