ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting byfirstAuthorbreaks email semantics

2008-02-01 14:49:45
 

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Frank Ellermann
Sent: Thursday, January 31, 2008 2:32 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting 
byfirstAuthorbreaks email semantics

MH Michael Hammer (5304) wrote:

By what mechanism do you know that the 4 authors (from addresses) 
engaged someone from domain E?

By definition (in RFC 822).


By definition you don't know. You only know that someone CLAIMS that it
is on behalf of someone else. Please cite the relevant section that
SHOWS the authorization - it doesn't exist. There is a presumption of
goodwill in the RFC that doesn't necessarily exist in a world where 85%+
of email is abusive (reference:
http://www.maawg.org/about/MAAWG20072Q_Metrics_Report.pdf )

We currently have no way of knowing that across domains 
other than the 
fact that the person from domain E claims it.

Yes, but you only somebody you wish to hold responsible, and 
if E signed it you have someone.  If nobody signed it, with 
E's SSP saying "strict signer", you can reject it.

It's a semantical matter, do you want to protect senders (as 
the name SSP suggests) or authors (in conflict with e-mail practice).
For the typical case one From, no Sender, there's no difference. 


Sometimes semantics actually matter. You have succinctly put the
question but instead of a binary (author/originator vs sender/injector),
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.

How frequently do we see authors/originators abusing senders/injectors
(other than compromised accounts or compromised hosts)? The more likely
(and common real world) scenario is individuals using sender to abuse
from.


What about the cases where domain E has no reputation?

Same problem as a PASS "From: A" (no B, C, D, E).


Not quite the same problem. From claims that it comes from A. It is DKIM
signed by A and the signature has been verified. As a receiver I can
make a link between the message and the origination domain for the
purported author. I have no conflict to consider. 

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.
Without a reputation - and if this approach is used for abuse - then the
likely outcome is that reputation systems will consider a domain without
reputation as significantly more likely to be abusive.

There is nothing that states that sender is authorized by the 
purported authors unless it is case #2

| originator  =   authentic                   ; authenticated addr
|                 [ "Reply-To"   ":" 1#address] )
|
| authentic   =   "From"       ":"   mailbox  ; Single author
|             / ( "Sender"     ":"   mailbox  ; Actual submittor
|                 "From"       ":" 1#mailbox) ; Multiple authors
|                                             ;  or not sender

You could 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>.

Without a method of authentication, authentic does not = authorized.
A claim of authentic/authenticated addr means nothing without a
recognized mechanism for authenticating. My personal hunch is that,
particularly given the examples used in the RFC, is that it was assumed
the person (From or Sender) was authenticated by logging into the
server. A kind of Mayberry RFD approach if you will.

The envelope sender is Mail From:. We are talking about RFC2822 Sender

Mike


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

<Prev in Thread] Current Thread [Next in Thread>