[ On Thursday, June 17, 2004 at 08:40:01 (-0400), David Brodbeck wrote: ]
> Subject: RE: [Exim] AOL - SPF - and EXIM
>
> > -----Original Message-----
> > From: Greg A. Woods [mailto:woods@most.weird.com]
>
> > > RFC2821 doesn't allow for rejecting mail just because the IP
> > > does not verify.
> >
> > Where-oh-where did you get that bogus idea from!?!?!?
> >
> > No RFC can ever dictate site security policies!
>
> I based that comment on this paragraph of RFC 2821, from section 4.1.4:
>
> An SMTP server MAY verify that the domain name parameter in the EHLO
> command actually corresponds to the IP address of the client.
> However, the server MUST NOT refuse to accept a message for this
> reason if the verification fails: the information about verification
> failure is for logging and tracing only.
Like I said, "No RFC can ever dictate site security policies!"
The language you quote above is invalid, as is the self-contradictory
language of RFC 1123 5.2.5. No RFC is perfect, and some are clearly
worse than others at stepping beyond the bounds of simply specifying
protocols.
Any site can choose to implement whatever policies they want and no RFC
can mandate that those policies are invalid or uncceptable or otherwise
a violation of the protocol specification.
The first rule in reading a protocol specification is to remember that a
protocol specification "MUST" not dictate policy -- i.e. it must not
dictate how and when the protocol is to be used! ;-)
Even an interoperability guide cannot _dictate_ policy to anyone.
I.e. if any site wishes to verify the validity of the HELO/EHLO
parameter and that site also wishes to use the result of that validation
in deciding whether or not to accept a message from the client, then no
rule in any RFC and no amount of hand-waving on the part of all us
RFC-pedants can ever be a valid justification for trying to clue-by-4
the poor innocent site's administrators for choosing their own site
policies. It's the RFC that needs a swift kick back to the editor, but
we all know how well that process works and we should just be glad RFC
2821 finally filled the slot that was reserved for it for so long,
flaws, warts, and all.
Heck if any site wishes to reject connections at HELO/EHLO time from
clients that have a single digit "2" in their IP addresses when
represeted as a little-endian 32-bit number in base-13, then the more
power to them!
Now, keep in mind that the SMTP protocol specification allows a
permanent error code (i.e. a number greater than 500 and presumably less
than 600) to be returned in response to the HELO/EHLO command and the
SMTP protocol specification also requires the client to interpret a
permanent error code for HELO/EHLO as a permanent failure for the
message being delivered in the current transaction attempt and that no
further delivery attempts be made for that message and that it be
returned to the sender address.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
