I don't see a terribly serious problem in checking
the message header as long as there's no forwarder.
There are at least two algorithms proposed to do it!
But clearly, there needs to be a good solution for
the 1+ Forwarder case (Sender -> Forwarder* -> Receiver).
I _think_ forwarders can be handled, without complicating
receivers, by using having the
forwader set the Resent-From or Resent-Sender header,
and using that as the field to check.
Both forwarders and receivers could then use SPF to
check message headers, without any specific settings.
That means MUAs will need to display that field when
displaying message bodies. There's the risk that
users won't notice this resending field (since the From:
value could be forged), but at least
the checked information will be IN a normal message header
(not just the SMTP protocol values), and it'd be
possible to train people to look at that (at least in
the medium term). Resending has been in the SMTP
standard forever, so email systems should be able to
handle them.
There are some minor annoyances when doing this.
Obviously, figuring out where email comes from is slightly
more complicated (because there are several headers to look at).
Many people (like me) get _ALL_ their
email sent via a forwarder, and if the "Resent-From"
were the primary field shown, all the email would have
the same sending value. Just always showing the "from"
value wouldn't be enough; a forger could set a bogus
"from" field, then "resend" it themselves -- users
would only see the unchecked value (!) if only looking at the
"From" field. Similar games can be played with "Sender".
But this might be okay, especially if there's a long-term
solution that would make it nicer to use. I think
the problem is that the receiver doesn't have quite
enough information to make things "nice"; if the receiver
(MUA or MTA) had a little more information, the information
could be displayed more "nicely". One way would be
to allow users to _also_ use the SPF format to specify
to their receiver their "trusted forwarders".
Any "Resent-" data from a trusted forwarder could then
be stripped off from normal displays (by the final MTA or MUA).
As long as this doesn't have to be done immediately for SPF
to work, but could be done in the long term (once SPF is
widely used), this might work. The same could be done
by intermediate forwarders; if F1 forwards to F2, and
F2 trusts F1 for that user, then F1 doesn't need to add
"Resent-" or F2 could strip that information.
The MUA could remove this information, but the problem is
that the information might change over time. Better to have
the MTA change the header fields if the user trusts the forwarder.
If the MTA and forwarder could be set to rename trusted fields,
then any MUA could easily highlight the "value actually checked",
and display that as the sender address (derived from From, Sender,
Resent-From, or Resent-Sender). WIth this approach, the sender
address would be what naive users would expect.
--- 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