On Tue, 2004-02-24 at 11:10, Hector Santos wrote:
SPF + MTA w/ HELO/EHLO domain checking = Good System
While the paranoid can check the EHLO for "spoofing", the argument
doesn't really mean anything. It _should_ mean something, but that is
an entirely different statement.
The number of _wanted_ messages rejected by EHLO checking is too high
for us to implement. Many large corporate systems do not use accurate
EHLO arguments -- and they are still RFC compliant. All of the use a
FQDN or IP literal are SHOULDs in the RFC. Infact, they can use HELO
(and you _must_ accept it by the RFC) and the RFC also implies that you
can completely omit the HELO/EHLO when says only that clients SHOULD
initiate their conversations with an EHLO/HELO.
I also don't agree with your equation. Not deviating from the RFCs and
not abusing other systems constitutes a good system.
SPF is designed to prevent fraudulent use of a domain the the return
path. The EHLO is not part of the the return path as I see it -- it
isn't even required. It appears in the trace headers if your MTA is
responsible enough to add it. To me SPF is not designed to prevent
abuse of the null envelope sender problem. And in my opinion, that is
fine. No one is fraudulently using my domain in their null envelope
sender.
SRS happens to be a technology/methodology design to tackle the null
envelope sender problem (and other things).
I see no reason by SPF has to "do it all". It has a stated purpose and
the current specification fits that purpose.
--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth