Hi !!
Adding one header field like you describe does not account for:
1. Multiple recipients
the header can contain more than one address
2. BCC cases where it is desirable to hide recipient address from
appearing in the email header
as the header should be added by a mta, that could be handled at
mta level.
Also note that original recipient can already be found (supposed
to be) in Received header fields (in the "for" clause) - though
is not quite the same because Received is added by next server
in email path rather then the one that originated email (in
practice however you can usually find if recipient has changed
or not by looking at received).
yes, it could also be found on To: or Cc: headers, but interpreting
headers not specifically intended for that purpose could lead to
errors (non standard formating, etc ...). Also that heades could be
completly faked. Having a specific header for that and a modifier that
says 'hey, all my messages have this header' will be better.
The system you describe requires that for every user receiving forwarded
email the system maintained list of addresses where the email is being
forwarded from. That is not easy to to implement at ISP level though its
possible at the final user recipient level if checking is done at MUA
(or webmail system like gmail/hotmail).
yes, this is something that has to be supervised by the user, either at
mua or at isp level.
If this is not done the system
is useless as then bad guys would just have to add this new header field
with any strange address in it so that bad SPF result is not counted
against them.
anyway a softfail/neutal result is also useless and bad guys don't
need to do anything to bypass it.
Yes, for something like this to work special SPF record policy would
also be required. This means that in practice taking "~all" to mean
"-all" would be safe since you know that is original user's intent (and
I would recommend not bothering with "neutral" at all).
not 100% true, some guys publish softfail for other reasons or when they
should publish neutral, having a %all (i.e) will avoid this kind of
misinterpretations.
But this does appear as something that maybe of interest for SID-like MUA
checking system (most likely checking on Sender header field if special
modifier is present like I proposed before), but not necessarily SPF
itself.
SPF itself has a big problem with forwarding, SRS is not the solution,
mainly because it will never be 100% deployed. The solution has to be
in SPF itself and it will need to be after DATA, or maybe we could all
switch to DKIM
--
Best regards ...
----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail david(_at_)ols(_dot_)es
Pintor Vayreda 1 telf +34 902 50 29 75
08184 Palau-Solita i Plegamans movil +34 670 35 27 53
----------------------------------------------------------------
-------
Sender Policy Framework: http://spf.pobox.com/
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