On Oct 5, 2004, at 11:34 PM, Hector Santos wrote:
IP: some non-winserver.com IP
HELO winserver.com
MAIL FROM: user(_at_)some-non-spf-domain(_dot_)com
While letting someone do the above doesn't make much sense, I have
received false positives on denying SMTP transactions like that (from
misconfigured mailers).
Still, the denial is trivial in any modern mailer by simply configuring
it to act that way. It doesn't require any extra code or protocols.
Why don't you just publish a document that says "everybody should do
this" (which I believe you've effectively done in posting this much
commentary) and leave it at that.
Saying that it belongs _in_ SPF is kinda arbitrary. SPF doesn't handle
the things that BATV or SES does (which are very valuable) or the
things that DomainKeys! does, should those go into SPF? I am all for
having clear, concise tools in the arsenal, not one kitchen sink. I
think it is great that these concepts have been formalized in concise
problem domains.
But it can't be ignored. Meng can't go on the promotion tour to talk
about
SPF implementation and when people begin to added it and still see 12%
of
the above like messages getting in, what do you think is going to
happen?
Sure he can. He's going to explain that a lot of things don't get
caught. SPF isn't about blocking mail from bad people. It's about
determining if the messages return-path is fraudulent. The hope is
that armed with that information, you can execute your other decisions
with more certainty.
So whether is it added or not inherently into the SPF1 spec, it is 100%
prudent to make it a provision in the documentation so that
implementors are
aware of this.
A agree, almost. If this needs to be in "the" documentation, then so
does the concept of BATV or SES and DomainKeys! But, since there isn't
"the" documentation and everyone is capable of writing and publishing
their own, each should publish the purpose, promise and specification
for their concept for protection formally.
Meng's done so, Mark's done so, Dave's done so... I commend you on
your fight on "Best Common Practices for Interpreting EHLO/HELO SMTP
Commands" and hope that you will formalize them once and for all and
have them published.
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: fastest MTA on Earth