On 05/27/2013 05:15 PM, Matt Simerson wrote:
Are you intending to inform all implementers and domain owners of this limitation with admonitions to search the list archives?
Searching is not required; this has been thrashed out so often and such length that any 10 randomly selected messages from the archive will likely contain several that argue one angle or another of this issue.
Your points about the weakness or absence of this information at several key places off-list are sensible.
Sorry, I missed the URL to the "Build an appropriate DMARC record" form that has the distilled wisdom of someone that has read every post to this list. Especially the official DMARC record creator tool with the "Do you have users that subscribe to email lists?" radio button that disables the rest of the form when I choose Yes.
May I suggest, as delicately as possible, that you [re-]familiarise with the obligations of all posters to this list and, in particular, with the requirement to remain cordial? http://www.dmarc.org/note_well.html
When I sent emails from my DMARC enabled tnpi.net domain to this email list, I got back reports from google and yahoo that they're blocking them. 513 google.com tnpi.net 2013-05-22 17:00:00 <snip> | -- 30 2001:1890:123a::1:1e reject fail fail mail.ietf.org forwarded mailing_list | -- 1 2607:f0d0:2101:bb::2 reject fail fail ericindustries.net forwarded mailing_list | -- 1 113.56.245.52 reject fail fail 113.56.arpa.hb.cnc.cn | -- 1 209.85.217.176 reject fail fail mail-lb0-f176.google.com forwarded mailing_list | -- 1 208.75.177.101 none pass pass mail.theartfarm.com <snip> | -- 1 2607:f8b0:4001:c03::234 reject fail fail mail-ie0-x234.google.com forwarded mailing_list | -- 113 208.69.40.157 reject fail fail medusa.blackops.org forwarded mailing_list
The only rejection listed above is the one by cnc.cn. The rest of the "assessed policy is reject" cases are situations in which the Receiver has locally over-ridden the Domain Owner's DMARC Policy, in each case because a reliable forwarder (specifically a mailing list) has been recognised.
It's worth noting that my observation that it's reasonable for a Receiver to map reliable forwarders and perform this kind of override does _*not*_ mean that it is reasonable for Domain Owners to assume that Receivers will do so. All participants in DMARC (and in email generally) need to assume that a material fraction of their communication partners will do unwise things.
It seems apparent that google detected that medusa is a list server, but they still applied my reject policy. When the receiver whitelists a list server, the results look like this: 519 163.com tnpi.net 2013-05-23 09:00:00 | -- 1 208.69.40.157 none fail fail mailing_list( forwarded by a white-listed mailing list ) medusa.blackops.org
That's how 163.com indicates it, sure. Google's indication of this outcome is closer to the spec and is you've shown above.
Had there been a warning label somewhere that DMARC + mailing list = BROKEN EMAIL, I'd have subscribed to this list with a different address.
As above, this is a good point and needs addressing. There's an even bigger warning label needed though: if your domain is not being heavily spoofed, you need to not use p=reject/quarantine at all. The reason is that the moment that you do so, a range of complications and dilemmas arises that require extensive domain knowledge to deal with. If you don't have the problem (being heavily spoofed), then you are better off avoiding the collateral damage entirely.
Now I'm exploring ways to work around the problem, so that I can still prevent phish from being sent from my domain.
How much phish is being sent from your domain at present?
Roland suggested not signing the Subject and body with DKIM, which is potentially another.
(cough) That was meant to be a straw man in that it was supposed to expose an obvious flaw: if you send a _*single*_ message signed this way to a publicly archived/subscribable list then a phisher can send an unbounded number of fully authenticated messages containing whatever he wishes until you actually delete mar2013._domainkey.tnpi.net from the DNS.
Sorry about that.
I'm also curious if the DMARC incurred deliverability failures will cause list users to inadvertently get unsubscribed. That would be an interesting side effect.
Enter the next dilemma for Receivers: silent discard causes message loss. SMTP refusal to an unmapped-but-reliable forwarder is likely to cause list unsubscription.
There is the potential for collateral damage almost everywhere. - Roland -- Roland Turner | Director, Labs TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693 Mobile: +65 96700022 | Skype: roland.turner [email protected] | http://www.trustsphere.com/
_______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
