Douglas Otis writes: > Dear Stephen, > > Perhaps my intent was obscured by thoughts of what's next. > Of course, nothing prevents DKIM/SPF alignment with the > Sender header field. Restating:
If it's signed by upstream and altered as RFC 5322 suggests it should be for mail which is received and reinjected, it will break the original signature if Sender was signed upstream. So what you're proposing, AFAICS, is already available and widely practiced: Mediators resign, and receiver ignore the broken upstream signature if the Mediator has a good reputation. Too bad for "policy", but the only people who actually *want* policy are the banks. Yahoo! and AOL at least have made it quite plain that they're happy to see mailing lists and other third parties working around p=reject. The only addition that TPA etc provides from the point of view of the user is a protocol for consulting the Author Domain for information about Mediators, but experience shows that Author Domains are not interested in providing such information. For example, when MLM admins ask them why mail isn't getting to subscribers, they refuse to answer in any specifics. They simply point to their AUP and third party acceptance policies, if any. Some domains even try to hide policy rejections completely by using a generic "permanent failure" status code. > Ignoring the Sender header field is appropriate ONLY when > just direct or transactional messages are issued by a > domain. If Dave Crocker had his way, we'd ignore From, too (I'm exaggerating here a bit). I can't agree with that extreme position (which I believe Dave doesn't actually espouse): even if we have no published proof that phishing via contact lists is substantially more effective than use of sibling domains etc, the theoretical risk is too clear to ignore. In any case we do have public proof that spammers think it works, and graphs that show that DMARC p=reject can prevent spikes as high as 6-10 times the background level of spam. > Only then are conflicts with RFC5322 avoided when asserting > restrictive DMARC policy. Restrictive conflicts are due to the > fact that DMARC lacks a means to assert the domain handles NORMAL > email exchanges. That's right, and AFAICS it's very difficult to improve the protocol because no Author Domain would want to grant carte blanche to 3rd party *domains*, unless it's known that they run as tight a ship as the Author Domain itself does. By "tight ship" I mean something like a domain that effectively represent a single trusted user with a relationship to the Author Domain. But the domains that are abusing p=reject have relationships with millions of domains, few of which are single-user and very few of which are trusted not to abuse "on behalf of" signing privileges. The mailing lists I care about don't qualify. Many of the innovative 3rd-party services (greeting cards, send-an-interesting-article, etc) are not going to qualify either, especially the startups. Many of these services look an awful lot like spam, too, even though recipients will tell you that they aren't. > In effect NORMAL messages will affect both DKIM and SMTP outbound > registration alignment fields. Handling NORMAL email exchanges > WILL cause policy requests based ONLY on From alignment to be > UNRELIABLE and INCOMPATIBLE with RFC5322. Yes, we know that. It was predicted well in advance of the empirical proof, as people involved in the early development of DMARC came to Mailman at least a year before the April Debacle with patches designed to break RFC 5322 conformance on behalf of posters at p=reject domains. > Currently ALL DMARC policy assertions ignore the role of the > Sender header field. Which seems theoretically correct to me, as (unlike From) Sender is not arguably a field reserved to Author Domains. Of course a Mediator can make an assertion about Sender by DKIM signing it, but it seems rather unlikely to me that Author Domains would want to make assertions about Sender along the lines of "if Sender is signed, consider the message to be authentic". At this point, of course you and Hector will bring up TPA and POLICY and claim it would be cheap and effective. But as a mailing list advocate with extensive experience of trying to get on the registries of the p=reject domains, of just trying to get information about why my mailing list seems to be banned, or even just getting confirmation that it *is* banned, TPA/POLICY strikes me as miscalculated chemotherapy -- you kill the patient before the cancer. > DMARC wrongly assumed the domain would limit its email to only > direct or transactional messages. When the Sender and the From > header field differ, ONLY the Sender header field can be expected > to establish domain alignments with SMTP outbound registration. That assumes that anybody actually wants to establish domain alignments, other than their own. I don't think that they do. I think they really want something much more flexible than that, able to assert that individual senders have their trust. If they really want to assert trust in anybody else at all. I see no convincing evidence that the p=reject domains would want to participate in these protocols, except to make arrangements with commercial partners (think Intuit's invoicing service) more standard and perhaps less costly. Mailing lists, they'd love to help us as long as it costs nothing to them. > Conditional alignment might include the identifier likely > being visible in the message or accompanied with an explicit > DMARC authorization. A receiver can never reliably resolve > a policy conflict caused by NORMAL email exchanges without > input from the DMARC domain. Of course they can. If Google Groups includes an A-R that shows that a message from a Yahoo! user was From-aligned, and signs that as well as the rest of the message, I'm sure that Gmail at least will consider that a reliable resolution, and ignore the lack of From alignment of the message as distributed by Groups. I would myself (if I ever subscribed to a Google Group :-). Thus we already have a mechanism by which Receivers can make their own decisions based on their own chains of trust, but DMARC purports to take that decision out of their hands. It fails to do so, of course, and IMHO that failure is a good thing. > Either SMTP needs to redefine roles for Sender and From header > fields OR DMARC must include provisions to properly include the > role of Sender. I disagree. AFAICS the Sender field has no interesting role here. The From field is singled out entirely because of its potential role in phishing attacks and recommender spam, that is, because of its role in identifying authors to end users. What matters to authentication of the sender is simply the security of IP addresses (in the case of SPF) and the security of signatures and the DNS (for both SPF and DKIM). By the nature of the protocols using the DNS, they also serve to identify the sending domain. > > > Many have not realized double signing is wide open to abuse > > > > Please present your threat analysis. > Even assuming a new scheme might extend DKIM expiry carried > within the DKIM signature to an authorized signature, this > would be problematic since mailing-lists expect > conversations to extend over fairly long periods. That's irrelevant. The whole point of the double-signing schemes is that they are per-message. The relevant period of conversation is the chain of SMTP transactions and Mediation from the boundary MX of the Author Domain to the boundary MX of the subscriber's domain. > Authorized DKIM signatures via double signing sidesteps > restrictive DMARC policy It's not a sidestep. It's a deliberate modification of the policy, applied to a single message. > where a resulting message can be replayed to any number of > recipients well beyond the control of the DMARC domain. This is a > general feature of DKIM so no special analysis is necessary. The > authorization is wide open since DKIM does not facilitate a means > to squelch any resulting phishing campaign. The time limit on delegation automatically squelches the phishing campaign within a few minutes, and once the decision to shut off delegation is taken, it would be effective in seconds, I suppose. I do not intend to downplay the bad consequences were such a campaign to actually occur, simply to point out that unlike the use of p=reject which requires action on the part of the Author Domain's administrator to squelch a malmail campaign (and requires some minutes to do so), the squelching that occurs with the delegation proposals is an inherent part of the protocol. Of course a new opportunity arises with each message sent by the duped author, but even here those messages can be shut down instantly (ie, delegation signatures are not added to any outgoing messages) at the administrator's decision. Messages already in the pipeline will continue to provide an attack vector, but they expire as quickly (or perhaps more so) than the TTL on DNS records. > How is double signing better than simply including the Sender > header field? Author Domains can make assertions about specific Mediators on a per message basis. While delegation may be too costly in practice to attract use, it's designed that way. This is better than any protocol based on Sender and a registry, because registry upkeep is clearly prohibitively costly when making per message distinctions or differentiating between different Mediators sharing a domain. > Acceptance can also be based on the Sender header field with an > expectation greater effort is made to ensure the Sender identity: > > 1) is included in the message. > 2) can be validated. (1) is already done because the sender's signature identifies it. (2) is extremely controversial because it requires solving the registration problem. I don't think it can be done in real time, and mailing lists already have enough problems getting the big providers to recognize their existence as anything except undesirable bulk mailers. > Our practice was to ensure a response to abuse within 15 minutes > using 5 minute TTLs. Consider the broken window theory. Being > unable to respond in a timely and effective manner "Unable"? I don't think you understand the proposed protocol. > makes authorizations wide open. This lack of control will > encourage higher levels of abuse. However, use of the Sender > header field would ensure the sending entity is held accountable. That's wishful thinking. Senders are already held accountable by RBLs and the like. The problem is that spammers have as many new senders as they need, while Mediators tend to have fixed identities, so that while such "accountability" raises costs for spammers, it kills mailing lists (or at the very least puts them on the disabled list until reputation can be repaired). _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
