spf-discuss
[Top] [All Lists]

Re: [spf-discuss] solving the forwarding problem

2005-09-10 17:36:40

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.

why ?

Its going to be impractical for certain cases of mass mailing from list
to to large ISP with many subscribers on that list. It would also violate
privacy built into email for those cases (you don't want one subscriber
to know about another one). Actually in almost all cases where there are multiple recipients unless those recipients are in "To:" and "CC:" adding their names in this field would not be appropriate for privacy reasons
(sae as BCC).

 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.

well, if you look at the received lines you will get that info,so there is no secret to keep.

I'm sure you will quickly notice that only when delivery is to a single
address is that address added into Received header line "for" clause.
Presumably also the forwarder that wants to keep the forwarding address secret would do so as well (but this is rare). As I said there is a difference between how Received are added and how you proposed to do it and there is a reason why such a difference exists. As well there is a difference between what user puts in "To" header field and what is in RCPT.

To be honest, even with new header field, I simply do not see how this algorithm could be used to "solve SPF forwarding" problem

wel, if you kown if a message has not been forwarded you could
turn softfail to fail, if the message has not been forwarded then
you could check if it comes from a known forwarding address.

It does not give you verified identity and does not authorize MAILFROM
for those cases. Solution must involve being able to do authorization
in all cases rather then only being able to bypass failures. Trusted forwarder and this algorithm are not solutions to forwarding issue - they are temporary intermediate actions to minimize the rate of errors and that is all.

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

well, it could be faked if the bad guys know which email addresses
forward email to every each user on the net. I think this is a bit
complicated to know if not impossible, so faking this header with
a bad address will cause a rejection.

Correct and so it would if there is a faked Received header line or
faked To. That is why I said that if bad guys forge it, it does not
matter because you only want to make sure real cases are covered.

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.

this looks good, if you relate the forwarder ip address, the sender
domain and the recipient, but it allows anyone faking the sender domain
to bypass the check using that forwarder. If you also check the header
after data you totally eliminate the chance of a forgery.

SPF does not offer strong per-email address protection in the first place. Whoever is sending through ISP mail server that you also use
can forge your name very easily.

Remember that SPF and DKIM operate at different identities, you can't substitute one for the other

yes, they are suposed to be complementary. But right now SPF is not
too useful if -all could not be published without having problems
with forwarders, so now you end rejecting a very small amount of
forgeries in spf pre-DATA checks and the real work is done after DATA

Nor can you easily substitute checks at RFC2822 stage for solution
intended to be used for SMTP2821 session and the other way around

i would mean that if the anti-forgery detection stage is to be done
after DATA, then why use SPF ? (just a philosofical question)

This "philosophical question" is really a question on that current
email system is not built very well and that is why you only have
two stages - envelope with very small number transport data fields
(and very hard to add new ones into system) and data with entire
message text, trace fields and authorship fields and some oter semi-transport fields all coming as one piece. It really needs
to be separated into several transport data levels.

Nevertheless what people appear to be looking for is not change
to some core parts of SMTP (as me and few others would prefer) but solution for current design parameters and that means you have to
deal with SMTP Session verification and Message Data verification
primarily separately.

Now, on most real cases almost all forgeries have the envelope recipient
address in the To: header, so a modifier in the spf record that says
'you could turn a softfail to fail if messsage has not been forwarded'
will stop most of them. The problem is that when people publish such
this modifier bad guys could just use a faked To:

It does not matter if they do or don't. If recipient checks if the the "To" and/or "For" address is one of his known forwarding address, then
all is fine, if its not, then its a forgery.

BTW - using To and For and doing DATA stage verification are not the
only ways to go. One possiblity (and this finally reminded me as to when I heard about this before) is using ORCPT extension which is passed as part of SMTP parameters and is by now supported by most mail servers. See RFC3461 (which updated earlier RFC1891 which first introduced ORCPT back in 1996) - http://www.faqs.org/rfcs/rfc3461.html. And obviously for senders starting to use ORCPT is no more difficult (in fact its easier
as its already standard) then adding new header field.

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