Meng Weng Wong announced:
Speaking of patches, I am going over the draft one more time and plan to
submit it to the I-D archive tonight or tomorrow. The working version
is 02.9.6.
Thanks for posting this!
As I mentioned in "Re: Some SPF concerns/questions", I think it's
absolutely critical that there be a _reasonable_ way that
people can check the ordinary mail headers for forgeries.
The current spec punts on this very vital point, saying:
"The <responsible-sender> depends on the presence and order of a
variety of headers, including Resent-Sender, Resent-From, Sender,
and From. Selecting the appropriate sender can be challenging
considering headers can be spoofed by malicious senders."
I believe you really need to add, after that text, a recommended approach.
Even if it's imperfect, if you put it into the spec, you have a LOT more
likelihood of getting it fixed by boldly placing something in.
And it's rediculous to think that by not specifying an algorithm,
somehow everyone will do the right thing. No one will know what to do,
so everyone will do something different, and that would be a disaster.
It'd be especially bad for forwarders, who need to know how to
make final receivers happy.
The two biggest problems are (1) fetchmail, which you can almost
certainly get fixed, and (2) handling forwarders.
If nothing else, forwarders can be handled by mangling BOTH the
envelope AND the contents (in the short term), and in the longer
term could be handled if end-systems supported whitelisting
of forwarding systems on a per-user basis. Or maybe there's a better
way (I hope so!). But the problem can't be ignored.
It's true that there are some broken systems; if possible, it'd be
a good idea for an algorithm to be given that's forgiving of them.
If it's truly awful, you eventually have to give up, but a forgiving
algorithm that handles conformant data well, as well as much non-conforming
data, will really help in uptake of the idea.
But if you don't put _AN_ algorithm in, people will just gen up a
really bad one. That's if they use SPF at all; if the "from:" can be
trivially forged, I think SPF doesn't buy much. SPF is _MUCH_ more
powerful if it can help what end-users actually see.
Roy Badami (roy(_at_)gnomon(_dot_)org(_dot_)uk) suggested on Tue Feb 03 2004 -
22:35:11 EST:
Roy> The header sender is defined as follows: in the case of a
Roy> message that has not been resent (as evidenced by the lack of
Roy> appropriate headers), the header sender is taken to be the
Roy> value of the Sender header, if present, otherwise the value
Roy> of the From header. Where a message has been resent (as
Roy> evidenced by the presence of appropriate headers), the header
Roy> sender is taken to be the value of the Resent-Sender header
Roy> (if present) in the first block, otherwise the value of the
Roy> Resent-From header in the first block. If the message is not
Roy> conformant to the syntax of RFC 2822, the behaviour is
Roy> undefined. A sample implementation is defined in Apendix
Roy> Foo.
I suggest rewriting it this way, which is a little more specific
in a few cases, and it specifies what to do
in the case of certain malformations (that spammers/forgers might exploit
if they're left unspecified). I've borrowed from Roy's previous
algorithm. Feel free to modify wholesale:
The header sender is defined as follows: First, determine
if the message has been resent (it's been resent if it containes
the headers Resent-From, Resent-Sender,
Resent-To, Resent-CC, Resent-Bcc or Resent-Message-ID).
If the message has not been resent, the header sender is taken to be the
value of the Sender header, if present, otherwise the value
of the From header. Where a message has been resent, the header
sender is taken to be the value of the Resent-Sender header
(if present) in the first block, otherwise the value of the
Resent-From header in the first block.
To locate the first resent header in a message, collect
all headers until a Received header is encountered or until
there are no more headers. Take the collected headers
(not including the Received header)
and discard from them all headers other than resent headers
(headers whose names begin with "Resent-").
What remains is the first resent block.
Many circumstances could cause a message to be considered malformed.
If the message is not conformant to the syntax of RFC 2822,
the message is considered malformed. Thus, if there is no "Sender",
"From", "Resent-Sender", or "Resent-From", the message is malformed.
If the selected header ("Sender", "From", "Resent-Sender", or
"Resent-From") contains multiple addresses, no addresses, or a
malformed address, the message is considered malformed.
A malformed message's response is undefined; it is suggested that
it be user-controlled to be considered "unknown", "error", or "fail".
By default a system SHOULD fail malformed messages, since
attackers might intentionally create malformed messages to avoid
authentication.
I think you could say that any receiving system that claims to conform
to SPF "MUST" do envelope checking and "SHOULD" do message header checking.
--- David A. Wheeler <dwheeler(_at_)dwheeler(_dot_)com>
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)œ§ÅvÂŒðŠŸØߎë ù1Ií-»Fqx(_dot_)com