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
