On Thu, 22 Jun 2006, Julian Mehnle wrote:
The point is that this corner case is very unlikely to happen unexpectedly.
While there may be legitimate reasons for 3rd party (isp.example.net) MTAs
to say "MAIL FROM:<(_dot_)(_dot_)(_dot_)(_at_)example(_dot_)com>", there is
really no need for them to
say "HELO example.com", and I doubt that this happens a lot. Perhaps
Stuart can give us some statistics on how often he has rejected messages
in such situations in the past?
Using for example, "yahoo.com" or "aol.com" as the hello name is *extremely*
common for spam. Of course, the real yahoo or aol servers have distinct
hostnames per rfc2821.
Any MTA that does not have a distinct hostname is broken. However,
Alex's example is valid, but fails to break my policy. To review in my own
words,
example.com is a distinct hostname for a server.
It is also an MFROM domain. The example.com MFROM domain must return
neutral because the example.com host is shared between several MFROM domains,
with no technical protection against forgery. Thus, the example.com
host is rfc2821 compliant, but can't get SPF pass for HELO.
This example would *not* reject the connection in my system, because
an MFROM SPF record takes precendence over HELO SPF, and presumably
all the domains hosted by example.com (including, obviously, example.com)
have SPF records. I reject on HELO SPF neutral only when there is no MFROM
SPF. (Yes, I realize this treats MFROM SPF NONE/NEUTRAL slightly differently,
but favors publishing SPF.) Only if example.com sent MFROM domains with no SPF
record would my system reject based on HELO neutral.
Try again Alex? No really. Your examples are *very* instructive, no
matter how contrived. They ought to go in a collection of "corner cases"
which would illumine the intent of SPF.
Also, I've put a *lot* thought into wringing every last bit of nuance
out of SPF records without penalizing SPF publishers. I even accept
permerror if the system can get a pass by heuristically guessing what
they meant, and sends a DSN complaining about the syntax error. (I need
to add what the system guessed they meant to the DSN. It currently just
shows the first mechanism with an error. This would also be a handy feature
for Scott Kitterman's SPF validator - not only tells you what's wrong, but
suggests a fix.)
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com