[ietf-dkim] email semantics (was: ISSUE 1525 [...])
nobody at xyzzy.claranet.de
Sat Feb 2 06:16:04 PST 2008
Michael Hammer wrote:
> There is a presumption of goodwill in the RFC that doesn't
> necessarily exist in a world where 85%+ of email is abusive
Yes. I'd put mailing lists overwriting my Reply-To into the
"abusive" category, and maybe a sender forging Reply-To can
be up to something really bad.
SSP or ASP won't protect Reply-To domains, I hope nobody adds
an "RSP" to the mix... :-) For the sender vs. author issue
I think (2)822(upd) suggest to pick their concept of sender,
not the alleged author(s) where they are different.
> let's phrase it slightly differently.....what are we trying
> to protect from? And if all we are trying to protect is the
> sender, why would receiving domains (or MUAs) have any
> incentive to use DKIM or SSP? The more likely answer is that
> we are trying to protect receivers.....from abuse.
A spammer claiming to be "sender: me" explicitly or implicitly
with an 2822 "from: me" without "sender: spammer" (or similar)
certainly abuses my address and/or the domain in this address.
That's relevant for receivers bothering to check it. On the
other hand "sender: me" with "author: you" (or similar) could
be a perfectly legit use of 2822 no matter what your ASP says.
It could be also "sender: whatever" with "author: paypal" in a
phishing attempt. Receivers white listing "paypal DKIM PASS"
won't get a white listed "DKIM PASS" for this phish.
> The more likely (and common real world) scenario is
> individuals using sender to abuse from.
True, but is that really relevant ? Why would I put the bad
guy "sender: whatever", assuming that results in a DKIM PASS,
on my white list ?
For MUAs showing "whatever on behalf of paypal" it is obvious
without DKIM, SSP, ASP, etc. that the sender was NOT paypal.
MUAs showing only the author(s) are IMO doomed. And receivers
thinking that an 2822 From is always true don't have the money
to use email and the Intenet, they have already lost everything.
> I can come up with 3rd party domains all day long (ok, I better
> hurry before ICANN moves on kiting/tasting) to sign arbitrary
[OT: Good that ICANN will stop this criminal practice. I hope
ICANN also terminates their "accreditation" of NetSol a.s.a.p.]
>> ask Dave what "authenticated addr" for <authentic> was supposed
>> to mean back in 1982 ;-) The sender is the "submittor" of the
>> mail - not necessarily to SMTP, the envelope sender can be
>> different in e.g. UUCP -> UUCP gateway SMTP -> SMTP scenarios.
> Haven't seen a bang path in a long while <G>.
Let's say RFC 1123 got rid of it. Other gateways not limited
to news2mail exist, I'm just not familiar with MMS, Mixer, etc.
(and I forgot the fine print of "fido/maus/z-net to rfc822" :-)
> The envelope sender is Mail From:. We are talking about RFC2822
Yes, I mentioned "not necessarily" just for the records. For SPF
it's important that folks don't confuse PRA with envelope sender,
or claim that it's almost always the same, because they've never
seen any email scenarios where that's plain wrong.
Ignoring legit corner cases will backfire, "issue 1525" is tough,
at least we're ready with the "first author" over-simplification.
More information about the ietf-dkim