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. 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.) > 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. > 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. >>| 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". [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) [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. >> 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" ? >> 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 _______________________________________________ ietf-dkim mailing list http://dkim.org
