Frank Ellermann wrote: > Jim Fenton wrote: > > >> I'm sure I don't mean "author". Repeating a bit of what I >> said elsewhere, what I'm trying to convey is "who it's from" >> > > Addresses in the From header field are only "guaranteed" to be > authors. Or rather "supposed", a guarantee is a job for DKIM. > > That MAY be also the sender / originator / PRA / poster, but > that depends, maybe not. > I stand corrected. I see in RFC 2822 that the address(es) in the From header are, by definition, authors (or alleged authors, at least). I'm learning to be very careful about words these days; I remember a little while back we had quite a discussion about the word "forgery" and whether DKIM did anything about it. I wanted to avoid falling into that trap with the word "author". > Your "informative references" include draft-crocker-email-arch. > The version I have is -04, and it says: > > | RFC2822.From > | > | Set by: Originator > | > | Names and addresses for author(s) of the message content are > | listed in the From field > [...] > | 2.1.1 Originator > | > | Also called "Author", this is the user-level participant > | responsible for creating original content and requesting its > | transmission. The MHS operates to send and deliver mail > | among Originators and Recipients. As described below, the > | MHS has a "Source" role, that correlates with the Author > | role. > > This is highly controversial. E.g. if I take your message and > send it to another list / newsgroup / recipient, then I'm the > originator, but you're still the author. And that's nothing > unusual, moderated newsgroups might be one example, another is > the Resent-* case, last but not least with news or UUCP before > a gateway to SMTP you could get various kinds of "originator". > > Better stay away from email-arch unless you can back up what > you need with (2)822. Bruce posted several (!) huge (!) lists > of objections wrt draft-crocker-mail-arch on the rfc822 list, > > (And I also wasn't pleased by its "bounces-to" POV, but that's > fortunately irrelevant for DKIM as long as you dance around > all "originator" issues.) > I intend to remove the reference to draft-crocker-mail-arch, and define the terms I need in this document. > >> as defined by what a typical email user would say when they >> look at a message. It's that address that really matters to >> them. >> > > Maybe, it depends on their UA, some display "on behalf of" for > an explicit Sender, and some might do something for PRA in the > future. UAs supporting List header fields probably exist, and > UAs not supporting the Return-Path at all would never be able > to do anything remotely related to RfC 3834. > Indeed. Even with "on behalf of" I think most people will still pick the From address (the part that comes after the "on behalf of").
Incidentally, I upgraded to Thunderbird 1.5 today and I see that it now shows the Sender address by default. > >> The reason I say "Typically the 2822-From" is that it's my >> belief that most users will point to it and say "It's from >> [whomever]". I looked at your message and said to myself >> "it's from Frank Ellermann", not "it's from >> ietf-dkim-bounces". >> > > Yes, I've written it, or rather somebody claiming to be me > behind the list or behind GMaNe. I'm the "purported author". > > The "originator" was GMaNe because that's where I (or somebody > claiming to be me) posted it in a newsgroup. At that time it > was author = 1036-From = poster. GMaNe treats almost all its > newsgroups as "moderated" NGs, because they are mailing-lists. > > For that purpose it sends the article to a "moderator", in this > case the DKIM list address. So the list got it with MAIL FROM > GMaNe (originator, SPF PASS), AFAIK also with a Sender GMaNe, > and with author = 2822-From = me. > > Finally the list redistributed it to among others you and back > to GMaNe, and only after that step it appeared in the GMaNe NG > corresponding to this list. Some news idiosyncrasies left out. > > That's the "normal" magic done by gateways and their operators, > desperately trying to figure out what some IETF documents talk > about. Here's the version enshrined in STD 11 (822): > > | source = [ trace ] ; net traversals > | originator ; original mail > | [ resent ] ; forwarded > > | trace = return ; path to sender > | 1*received ; receipt tags > > | return = "Return-path" ":" route-addr ; return address > [...] > | 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 > > | resent = resent-authentic > [... etc., received and resent-authentic omitted ...] > > Change a single word in this semantics and the bloodshed hits > the fan. > I agree with your description but I don't see where it affects the Threats document. If you're just explaining something, that's fine, but let me know if I missed a point. > >>> | Ability to "wiretap" some existing traffic >>> > > >>> ...OTOH that's rather special, isn't it ? No problem with >>> listing it as possibility, of course, if it later turns out >>> to be related to DKIM in some way. >>> > > >> I don't see it as being much more special, or difficult, than >> manipulating IP routing. >> > > ACK. It's something I also didn't like for SPF. There are of > course ways to attack something in the lower layers, and there > should be pointers to relevant documents like RFC 3552 and 3833 > in the security considerations, the former maybe replaced by > draft-klensin-rfc2821-security later. > > But I'm more interested in threats and security considerations > for DKIM itself, not stuff like IP-spoofing, DNS poisoning, or > DDoS attacks on DNS. Not our job to secure DNS, you only have > to make clear that DKIM depends on a working and reliable DNS, > otherwise it's "ex falso quodlibet". > Where did that Latin dictionary go... > [AU vs. MON / MRN] > >> I'm happy to use any term that fits but I want to be >> consistent. Is there a definition of MON somewhere that I >> can read and refer to? >> > > Yes, Keith published it on the SMTP list in conjunction with > the IETF last call for the old draft-hutzler-spamops-04: > > http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html > > You could read a thread about it using GMaNe: > > http://news.gmane.org/group/gmane.ietf.smtp/thread=4383/force_load=t > > You'd be forced to copy what you like for a definition of the > terms MON and MRN. It was also discussed on the general list: > > <http://article.gmane.org/gmane.ietf.general/17506> (Sam) > <http://article.gmane.org/gmane.ietf.general/17506> (Bill) > Thanks. It's looking like MON and MRN are the terms to use. > [3.1 DKIM "mitigating against the use of addreses" <g>] > >>> That's unclear, which addresses, author(s) / sender / PRA ? >>> >> If you consider SSP, probably "originating address". >> > > Yes, but _which_ address, From / Sender / Reply-To / PRA ? > > For STD 11 see above: "originator" is the part of "source" > without the "Return-Path" or Resent-*, so that would remove > PRA from the equation leaving From / Sender / Reply-To. > > Keith uses "return address" for the set 2822-From / Reply-To / > 2821-From (Return-Path), you don't want the latter, so that's > no alternative. Draft-ietf-usefor-usefor-06 offers "poster" > if you don't like "author" (maybe not a good idea for DKIM): > > | A "poster" is the person or software that composes and submits > | a possibly compliant article to a "user agent". The poster is > | analogous to [RFC2822]'s author. > Author is fine since it's defined that way in 2822. > >>> What do they sign it for if they're not accountable ? >>> > [...] > >> This is that paragraph I need to rewrite, because I was >> thinking about the individual that is the administrator of >> the domain, but of course DKIM doesn't trace accountability >> to individuals who are domain owners, only to the domains. >> > > Okay. It's odd to work on the "security considerations" before > the protocols (base + SSP) are clear. Are you supposed to do > this _three_ times, once to get the WG chartered (ready), again > because the charter says so as some kind of input feedback loop > back into the WG to get base + SSP right, and for a third time > after base + SSP are ready, or integrated into their "security > considerations" ? > Hopefully not, but we'll see. > >>> Maybe a stupid metaphor, AU is like NFKD, MON + MRN like >>> NFKC, both are fine, but you need the latter for your >>> threats draft. >>> > > >> You lost me on the metaphor. I assume you mean the Unicode >> acronyms NFKD and NFKC? >> > > Yes. Dave's mail-arch decomposes the mail architecture into > AU pieces with various roles, an AU for any given role is a > bit like a NFKD (set of compatible decomposed charaters). > > OTOH Keith aggregates various AUs and what else on the side > of the originator (MON) or receiver (MRN) resp. Dave's term > "mediator" is also some kind of aggregation / composition, any > middle man not belonging to the initial MON and the final MRN, > like a mailing list. > Bye, Frank > Thanks. -Jim _______________________________________________ ietf-dkim mailing list http://dkim.org
