[ On Saturday, June 12, 2004 at 22:19:28 (+0100), Alan J. Flavell wrote: ]
> Subject: Re: [Exim] AOL - SPF - and EXIM
>
> On Fri, 11 Jun 2004, Greg A. Woods wrote:
>
> > RFCs cannot mandate site security policies. Period.
>
> In practical terms, I agree,
>
> > You can 5xx right at HELO if you damn well feel like it, just as you can
> > 5xx at greeting time.
>
> Quite how you square that with the mandate to accept postmaster mail
> is unclear.
The same or similar security policies may apply to <postmaster> as
well. No RFC can mandate site security policies, no matter what the
reason. Period. :-)
> If you're going to reject mail before you even know who it's for, how
> are you ever going to deal with attempts to report false positives to
> the postmaster?
There's no such thing as a "false positive" when the reject is for a
security policy that has nothing whatsoever to do with the recipient
address and everything to do with the client-SMTP and/or it's DNS.
E.g. if your site has chosen not to accept SMTP connections from dial-up
clients (e.g. those listed in some DNSBL dedicated to such things), then
it doesn't matter who's behind the sending client or who they are
attempting to send to.
> > If you reject at RCPT time based on your dislike of the HELO parameter
> > then you're only confusing the sender, at best.
>
> If their client fails to present our explanation to them, then that's
> surely their problem?
No, not really. By delaying your response you botched the SMTP protocol
and confused their legitimate and RFC_compliant error handling. You
can't expect everyone to be able to read and understand your error
message -- and the SMTP protocol was designed in such a way that no such
expectation is valid or necessary.
> > You're saying at the
> > protocol level that you don't like that recipient address
>
> No, we're saying that we don't like that recipient address *taken in
> combination with other features of their previous actions in the
> transaction*.
No, you are most definitely _not_ saying that. There's no way in SMTP
to say any such thing at all. You are _only_ saying at the protocol
level that you don't like that recipient address. Period. RTFRFC. :-)
You sent a permanent error response code to a "RCPT TO:" command and you
_MUST_ expect the client-SMTP implementation to interpret only the code
number and to interpret it only in the immediate context of the command
it just sent.
Everything else is gravy. In an ideal Bablefish world where all of the
text accompanying the response code was always presented to the
originating sender then all would be well, but you and I both know full
well that such a scenario is way beyond even a blue-sky dream. Luckily
a proper SMTP implementation does not require such a dream to come true.
I.e. fix the real problem -- not the second- or third-level symptoms.
> But if we reject them at HELO time, how would we ever know?
How would _you_ ever know _what_?!?!?!?
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
