ietf-dkim
[Top] [All Lists]

[ietf-dkim] email semantics (was: ISSUE 1525 [...])

2008-02-02 07:19:36
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
messages.

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

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.

 Frank

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html