"David A. Wheeler" <dwheeler(_at_)dwheeler(_dot_)com> writes:
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.
I'm certainly very concerned about forwarders -- because I run one in
my basement. Kind of a worst-case situation for this -- doing the
complex thing, but no budget and no "real" sysadmin. A number of the
virtual domains primarily forward email, and that's the only useful
way to run them (telling people you're giving them *another* mailbox
to check, that they have to remember to look at regularly, is NOT
going to fly). So I'm keeping an eye on the forwarding issues. I
must admit that the proposed hackery looks really ugly. I'm also a
bit worried about what happens with multiple levels of forwarding.
However, it's running with qmail, so if you come up with qmail patches
to do "the right thing" and it all really works, then that'll be
okay. I need to find time to satisfy myself that we agree on "the
right thing", though :-).
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.
I think you're under-valuing the things SPF actually *does* do. If
the envelope sender is more reliable, then it can be used in
reputation schemes. That's a *very* powerful step up in the fight
against spam IMHO.
On the other hand, you're right in that the fraud cases that figure
prominently in the publicity all relate to the From: header, not the
envelope sender.
I think, in fact, that SPF is better as an anti-spam tool (which it
mostly disclaims) than it is as an anti-fraud tool (which it
advertises).
--
David Dyer-Bennet, <mailto:dd-b(_at_)dd-b(_dot_)net>,
<http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com> <http://www.dd-b.net/carry/>
Photos: <dd-b.lighthunters.net> Snapshots: <www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
-------
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_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡