spf-discuss
[Top] [All Lists]

Re: [spf-discuss] solving the forwarding problem

2005-09-10 08:58:58

On Sat, 10 Sep 2005, David wrote:

Hi !!

Adding one header field like you describe does not account for:
 1. Multiple recipients

the header can contain more than one address

It can but its not worth it.

 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.

You don't understand about BCC if you answered this way. To put
it another way, not every sender (be it at MUA or MTA level) would necessarily want to show to end-user recipient the address to which
it actually sent email to.

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

No, it could not. Like "From" and "Sender" RFC2822 header fields are
not the same as RFC2821 MAILFROM, so is true that To and CC are not
the same as RFC2821 RCPT TO.

[But it would be good to keep in mind that if Received "for" clause
 algorithm fails to provide good address then "To" and "CC" could
 potentially be used (or other way around, i.e check "To" and "CC:"
 fields for known forwarding address against user's list and if not
 found then go after Received lines)]

, but interpreting
headers not specifically intended for that purpose could lead to
errors (non standard formating, etc ...).

To be honest, even with new header field, I simply do not see how this algorithm could be used to "solve SPF forwarding" problem - as others indicated to you, it would run contrary to what SPF is supposed to be
used for and how. And it really would not actually allow to authorize
the MAILFROM (or some other) address - just allow to bypass the check
in some cases and this is not a solution long-term.

I do see its potential as part of complex spam filter to be used
on current email infrastructure (but not in accept/reject way for
this algorithm alone).

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.

It does not matter what header field you interpret - they could all be faked. And in this case faked header field really does not do anything for the bad guys (unless they know your forwarding address so as to properly fake the field).

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.

And doing such rules at ISP level is difficult to implement - although SIEVE is your friend of course :) Where ISP's own trusted forwarder list (based on what its users provided to it) is a lot easier to keep up at ISP level and allows to bypass failed SPF checks at the SMTP level rather then at DATA.

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.

All have some use as part of overall spam filter. And by increasing accuracy and removing bad softfails you end up with fairly good results for such filtering rules. Obviously softfail would not solve the actual MAILFROM forging problem, but rcpt-to "bypass" system would not solve
it either.

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.

If you have special modifier and with that modifier you know that "~all"
is to be interpreted as "-all" in such and such case, then that is what
you do, i.e. you then know that is the sender's intent. If sender otherwise
wants to publish ~all, they'd have to settle for ?all instead (of course new %all would be better indicating this particular situation, but it would not be compatible with spf1).

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

Remember that SPF and DKIM operate at different identities, you can't substitute one for the other (actually DKIM is badly designed and not make it clear what identity it is supposed to operate on, but its definitely not RFC2821 MAILFROM identity). Nor can you easily substitute checks at RFC2822 stage for solution intended to be used for SMTP2821 session and the other way around (its possible but you have to be very careful how you mix it, so you don't get it wrong as far as separation
of RFC2821 and RFC2822 data in current email architecture).

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

-------
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