Anne Bennett writes: > >> But if I understand correctly, it's being suggested that for > >> various proposals made here to work, either the sender's mail > >> system or the final receiver's mail system would have to become > >> aware of all
"All" has been asserted. Why it needs to be "all" has not been explained, and when I ask that question, the response I get is "because I don't think you can get close to 'all'". (I expect the next round to go "So, why do we need to get 'close to "all"'?" "Because I don't think you can get close to 'close to "all"'. Young man, you are very clever, but it's 'can't get close to' all the way down!" ;-) > >> of the "legitimate" (definition purposely left > >> out!) mailing lists to which its users subscribe. [...] > But I thought the point of DMARC was to determine reliably > (using cryptographic keys and/or IP addresses as published by > the alleged originating domain in the DNS under their control) > whether the domain in the "From:" header is really responsible > for originating a given message, It's only half-reliable. A DMARC pass is reliable per protocol. A DMARC fail is 100% unreliable (SHOULD NOT be considered to provide any new information that isn't available outside of the DMARC protocol). > and I thought the problem we're trying to solve here is how we can > prevent DMARC from breaking "mediated" mail (such as mailing list > mail). > > - Munge the "From:" header to have the mailing list "take ownership" > of the message, at least for messages sent by users in p=reject > domains - which is already implemented as an option in at least one > major MLM, but is not popular philosophically (because people > expect the From: line to specify the author of a post) It's worse than that. RFC 5322 (like all of its predecessors) *specifies* that the content of the From field is the author's mailbox (or authors' mailboxes) and optionally name(s) or other description. > or in practice (because it makes it harder for the recipient to > choose to reply to the list or to the original sender as they > wish), > > - Come up with a scheme allowing the mailing list to "re-sign" > a slightly munged version of the message, which is what > I think we're arguing about. > Well, I myself wouldn't call something a thing of beauty when it > wrecks the functioning of mailing lists when used as intended, but I > also think it's pointless to try to specify a protocol that allows for > implementation-dependent heuristic decisions to "solve this > problem". "Legitimate" is always heuristically determined by the receiver, as you argue below. So people who argue that policy should be an absolute determinant of disposition just don't use the same Internet the rest of us do. > Any e-mail provider can already arbitrarily decide to ignore DMARC for > mail they think is list mail, if they want to. That doesn't help. To solve the problem lists face, *all* recipients *must* ignore DMARC. Otherwise subscribers at domains that *do* respect p=reject get their bounce counts increased while not receiving desired mail. > Sure, then they couldn't call themselves "DMARC compliant", but who > would lose sleep over that? Nobody, since they *can* call themselves conforming as long as they report. Accepting mail from a p=reject domain that fails the From alignment test is explicitly permitted (with "MAY"). > If I can step back a bit, all DMARC does is ensure that the site in > the "From:" line signed (or, via SPF, transmitted) *this* message. > A malefactor can send DKIM-signed or SPF-approved messages as easily as > anyone else. And in fact, any malefactor can send from Yahoo! or AOL, and get those domains to sign their messages. It's more difficult, but they can even send malicious mail "From" those domains, which will be signed if it does escape the outgoing filters. > Some of the proposed solutions involve a mediating site making > modifications, and signing its specific modifications. We already do sign messages, although in most cases it is not possible to identify the specific modifications with current protocols. I am sure that many large providers already maintain reputation databases for quite a few mailing lists, and those signatures help get our mail through to their mailboxes. > Nothing about DMARC or DKIM states that a message is okay - that part > is checked by other (yes, heuristic) parts of the mail system. > Nothing about an expanded DMARC or DKIM with "re-signing of > modifications" needs to be construed as stating that a message is > okay. > > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. It's not a red herring. Identifying lists and other frequent senders of indirect mail, and only authorize resigning by those who pass further heuristic tests for "legitimacy", is an useful heuristic. Without a plausible approach involving reasonable cost to generating such a list, delegation protocols won't fly. I just don't think solving the "registration problem" should be a blocker for developing a delegation protocol, because the List-Post heuristic is a good start for any size of domain. I'm sure the large domains can do *much* better for themselves, and for smaller domains we can help develop substantial improvements, including sample implementations in software. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
