On Feb 4, 2010, at 7:57 PM, Chris Lewis wrote:
Bart Schaefer wrote:
On Feb 4, 4:18pm, Steve Atkins wrote:
}
} There's a subtle implication, which is that if you're stashing the
} ARF consumer address in a header, and your MX isn't overwriting (or
} stripping) that header, then it's possible that spam reports could
} be sent to the preferred reporting address of someone further up
} the delivery chain. I see this as an advantage, but it needs to be
} mentioned.
This is exactly the point I was making, over at the head of another
sub-thread. If a reporting address can come in from somewhere up the
chain, then it can come in *forged*, and whatever software is going
to interpret the address needs a defense against that.
Numerous proposals for dealing with this (and arguments about why it
isn't necessary, or in Rich's case, why it's irrelevant) have already
been bandied about.
It happens ;-)
The basic thing is that either the MUA knows how to handle ARFs without
relying on anything the mail stream (user config of where to send ARFs), or
has to know that the message path supports abuse reporting (user
configuration boolean switch), it can trust ARF directive[s] in the headers
AND that the message stream HAS to take steps to destroy any ARF directives
it doesn't want its downstream users to execute.
If either the above are true, you don't need to go to extremes to, say,
cryptographically secure ARF directives and put all sorts of trust-evaluation
gunk into the MUA. Putting the latter in MUAs would be a big istake.
But if you do inband ARF directives, if the originator sets ARF strings, it
needs to not DKIM that header ;-)
I'd rather not burden the user with any configuration at all, and if you have
to have the user do something, the lesser the better. That isn't a big deal
in environments where the users are running site-preconfigured MUAs (like
us), but becomes an issue elsewhere, and you have to tell the user what to
set it to.
The advantage of MUA-only configuration is that you don't have to touch the
MTAs at all to make it work. Indeed, if you want to outsource your ARF
handling, or the user wants to do them anyway, you only have to make your MUA
TiS capable, no other changes required. That may outweigh all other
considerations.
Also, if the failure mode is that the original sender of the email can cause
feedback loop reports to be sent to any email address they like there aren't
many real concerns.
First, confidential data. The only data that might be considered confidential
is the contents of the original email (that's all there is in an ARF report
other than a little metadata). The sender already has access to that, so it's
pretty much a non-issue. (Most anyone can sign up for a feedback loop with
consumer ISPs today, and there's not any obvious abuse of the data possible).
Second, use of the FBL for harassment. It's not a great channel for that, as
even theoretically it can cause at most one email for each original email sent
out. More realistically it's more like 1:100 or so, as pitching an email such
that it'll get through someones spam filters to a recipient, but still be
objectionable enough for them to hit the TiS button is tricky enough, and any
mail sent to any ISP that was aware of this protocol (to the extent of
overwriting or deleting the relevant header) wouldn't count. Less of an issue
than return path or reply-to.
And that's about it. There's not really any need to "defend" against "forgery"
at all.
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg