[ On Thursday, June 10, 2004 at 10:19:44 (+0530), Suresh Ramasubramanian wrote: ]
> Subject: Re: [Exim] AOL - SPF - and EXIM
>
> Avleen Vig wrote:
> > On Thu, Jun 10, 2004 at 02:11:20AM +0100, Alan J. Flavell wrote:
> >
> >>The key clue, in most cases, is that the counterfeiters presented HELO
> >>domains that either say aol.com, or else they contain one of our
> >>domains, despite the fact that the calling IP indicates that their
> >>presented HELO domain has no relation whatever to either AOL nor us.
> >
> >
> > and, iirc, RFC says you shouldn't reject because of HELO data :-(
>
> I disagree. The RFC at most says you shouldn't 5xx right at HELO
RFCs cannot mandate site security policies. Period.
You can 5xx right at HELO if you damn well feel like it, just as you can
5xx at greeting time.
If you 5xx at greeting time though you can expect the transaction to be
retried.
If you 5xx at HELO time (for whatever reason) you can hope the
transaction will not be retried (and it won't be retried except by
extremely broken and non-compliant software).
> 5xx'ing at RCPT TO based on HELO data is a perfectly valid way to go.
Well, no, it's not, at least not if you are even a tiny amount concerned
with the possibility of rejecting legitimate mail.
If you reject at RCPT time based on your dislike of the HELO parameter
then you're only confusing the sender, at best. You're saying at the
protocol level that you don't like that recipient address then nine
times out of ten you're going to end up making the sending user think
they mis-typed the address or that their friend no longer has a mailbox
at your domain.
I.e. leaving the 5xx to RCPT time instead of sending it at HELO time
when you should is just plain stupid and violates the _intent_ of the
protocol design almost infinitely more than sending the reject at HELO
time when you should. Remember that the explanitory text of the message
you send along with the 5xx response is often lost, and is almost always
totally meaningless to any normal human anyway. If ordinary users can't
even figure out what "over quota" means then how the hell do you expect
them to realize that the fault is either with their server's
configuration, it's DNS, or with some other policy related function
that's specific to their _server_ and not in any way related to the
recipient address that was actually rejected. Keep in mind that even if
you use a code like 554 and you provide a meaningful enhanced status
code too, the legitimate sender's own mail server will almost invariable
construct a DSN that at best will provide a contradictory explanation
for the error and more likely will simply not show the sender your
reject message text at all.
If you reject at HELO time, regardless of whether it's for policy
reasons or just because you don't like the letter "z" in their domain
name, the DSN written by the sender's mail server will not be even
remotely anywhere near as likely to confuse the sending user into
thinking there's something wrong with the recipient address and their
own postmaster will be far more likely to get a clue as to what's wrong
too.
Don't pervert the protocol error handling just because you're worried
about some idiot telling you that you're not honouring a self-
contradictory and out-of-bounds and ancient RFC rule that was only ever
published as a political compromise in the first place.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
