Don Lee wrote:
It does not provide enough information to make a definitive judgement
about whether email is "legit" - and it never will.
It can be used to make this judgement. If you get a PASS claiming to
be MAIL FROM "me", and you know "me" (in your address book or another
kind of white list), then the mail was likely sent by "me" (or by a
zombie on my box, or by another customer of the same ISP, etc.), but
you can ignore this and hold "me" responsible if it's spam, and let
"me" figure out how to convince my ISP to prevent other users of this
ISP from forging my MAIL FROM.
SMTP AUTH (RFC 2554bis in last call) and SUBMIT (RFC 4409) exist, it's
possible to get this right on the side of the sender. And FWIW it's
also possible to tell receivers when cross-user-forgery should never
happen, with an op=auth (dubbed as HARDPASS).
An SPF PASS from a known sender is a good thing. But a PASS is also
fine from unknown senders: Receivers can be sure that bounces to a
PASSing envelope-sender never hit innocent bystanders. The "sender"
states which outgoing routes are permitted (i.e. PASSing), and nobody
else can manipulate the sender policy.
Let's focus on those uses of SPF that provide precise, reliable data,
and how those can be used.
For a PASSing envelope-sender see above. For a FAILing envelope-from
you can reliably tell that the SMTP client IP is not permitted in the
checked sender policy. Of course the policy could be erroneous. Or
the SMTP client is an MTA behind the border MX of the receiver (= one
of your own from the POV of the receiver), and then checking it makes
no sense. Or it's an IP of a forwarder outside of your organization,
and then an enumeration of permitted IPs by the sender can't help -
either you know that it's a forwarder, or you don't and reject FAIL.
HELO checking is a good example. I think there is consensus that
this is safe and effective, and can be deployed immediately
everywhere without pain. I think we should push this.
Yes, that should be in a separate document, and some weeks ago I and
Scott volunteered to write it at some point in time. But then we got
distracted by HARDFAIL and other oddities. At the moment it's IMHO
more important to steer the charter of the planned 2821bis IETF WG
in the right direction, "keep anything as is" is a horrible proposal.
So far only one poster supported my objection, and the folks trying
to pull the "2821bis to draft standard as is" stunt are an almost
complete list of the IETF mail and SMTP gurus (John, Ned, Dave, Tony,
and others). If anybody here has an opinion about "the originator as
indicated in the reverse path" and intends to say it in this future
WG: As soon as an IETF WG charter is approved it's almost impossible
to modify it. So better say it now on the SMTP list.
[back to HELO policies]
it can be very effective in blocking spam bot-nets and the like that
forge HELO names.
Yes.
Chasing corner cases and forwarding issues detracts from this goal.
It's probably necessary to discuss this again and again. Folks like
SPF because all that's needed to understand the idea is common sense.
And then some don't want to pay the price because it "breaks" legacy
forwarding. But that's no bug, it's one the three essential features
(counting PASS + HELO). If they don't like this they can still use
PASS + HELO, or try some SES-exists magic not affected by forwarding,
or check out combos of BATV and DKIM. If they still don't like it I
recommend to use jabber instead of mail. SMTP is just as it is.
Frank
-------
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/?list_id=735