> On 14 Aug 2020, at 17:18, Dotzero <[email protected]> wrote: > > > > On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins <[email protected] > <mailto:[email protected]>> wrote: > > >> On 14 Aug 2020, at 09:27, Dotzero <[email protected] >> <mailto:[email protected]>> wrote: >> >> Now I have come to the conclusion that they should reject list submissions >> from accounts at domains which publish a DMARC policy of p=reject. Domains >> should not be able to externalize their internal problems to others. > > This effectively cuts off users at multiple ISPs from ever participating in > mailing lists. Which is exactly what we’re trying to fix with this proposal. > > Does the proposal actually fix the problem? Does the proposal actually fix > the problem without creating other problems? After reading an re-reading > Dave's draft, my conclusion is that the answer is no to both questions.
And that’s why we’re having this discussion, to determine if it does or not. > > Just because a user has an address at a consumer mailbox provider that > publishes p=reject does not make them a second class citizen banned from > participating in any mailing list. > > You are conflating the provision of Internet connectivity with the provision > of email services. That ship sailed a long time ago. There are a number of > ISPs which no longer provide email accounts/port 25 services. If a user with > an account at one of those domains wanted to use their login as an email > address are you suggesting that others should send responses to that "email > address" even though no MX is available for that account and mail will never > reach that user? I was speaking of companies like Yahoo and AOL, companies that provide email services and not internet connectivity. They publish p=reject and any solution that is ‘well, they just don’t get to use mailing lists” seems to create a problem. At one point, gmail announced they will be publishing p=reject, which meant users of 2 of the 3 major consumer mailbox providers would be prohibited from joining mailing lists. > It is clear to me that a domain owner/admin has the right to determine how > that domain will or will not be used. The individual is not banned from ever > participating in a mailing list. They simply can't use an account from that > particular domain. There are plenty of other places they can get an email > account from. They also have the opportunity to tell their existing provider > they are unhappy with policy. Providers can and do change their policies. For > the longest time, the address block associated with Amazon Simple Mail > Service was a swamp of badness. Legitimate users and organizations started > deciding to not use other Amazon AWS services as a result of their mail being > blocked. Amazon got religion and started cleaning up their mess. So yes, even > large players can respond to market and community pressures. > > I'm not the person who initially suggested MLMs reject users/email from > domains that publish p=reject. That was John Levine. Perhaps he was being > sarcastic, perhaps not. It is certainly a forcing mechanism. And that may > just be what is needed for domains to think carefully about how they > implement DMARC. That is not how the quoting came through on my client. I was attempting to be succinct and trim the message. Here’s the full email I was responding to. In my client you appear to be the one saying MLMs should reject anyone using a domain with p=reject. If the quoting was incorrect, I apologize for the mistake. > On 14 Aug 2020, at 09:27, Dotzero <[email protected]> wrote: > > > > On Thu, Aug 13, 2020 at 10:08 PM John Levine <[email protected] > <mailto:[email protected]>> wrote: > In article > <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=99yvu0dglz-z19i...@mail.gmail.com > <mailto:[email protected]>> you write: > >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers > >from a similar problem as PRA in the SenderId draft. There is no way to > >validate that the specific intermediary is authorized by the (From) domain > >originating the email through it's generic signalling that it > >authorizes intermediaries. This means that any source can emit a message > >claiming to be a legitimate intermediary just as any source could game PR > >to gain a neutral result. > > That's a feature, not a bug. I want recipients to be able to assess > the mail my lists send on its own merits. > > And recipient domains do just that using local policy override. DMARC policy > is at best a request to the Validator/Receiving Domain. If a > Validator/Receiving Domain chooses to honor the published DMARC policy for a > domain such as p=reject, then they are in fact assessing the mail your lists > send based on the merits as they see them. The same goes if they decide to > not honor that published DMARC policy and accept mail from your lists. > Earlier in my DMARC journey I felt that MLMs should adjust and send list mail > as themselves. Now I have come to the conclusion that they should reject list > submissions from accounts at domains which publish a DMARC policy of > p=reject. Domains should not be able to externalize their internal problems > to others. > > >One could achieve similar outcomes using > >only reputation and local policy override of DMARC policy. > > Only if you believe that the domain on the From: line is automatically > more credible than the one on the Sender: line. The whole third party > problem is that the people sending their mail through lists or > whatever are in fact doing so legitimately, but for various reasons > their organizations' DMARC policies lie and say they aren't. > > I think you are misusing the term "credible". Domains which are publishing > p=reject policies are making an assertion regarding mail purporting to be > authorized by their domain. It is not an assertion that their mail is "good" > or should be delivered to a recipient or even given preferential treatment > with regard to filters or policy. The assertion is simply that mail > purporting to be authorized by my domain must pass either SPF or DKIM > validation or else we request that in the event of neither of these properly > validating for a particular email message, please reject this message. Don't > think of it as being about "legitimate" or "not legitimate". There is a > certain (normally small) amount of mail that fails to validate even when it > passes directly from the outbound MTA to the recipient domain's MTA. The > sending domain is accepting that this otherwise valid mail may (SHOULD?) be > rejected by the receiving domain. The organizations DMARC policies aren't > lying. They are simply saying "If this then that." > > This ultimately goes back to the elephant in the room. Does an individual > user's use of an account at a domain trump the organization's right to define > how an account at a domain may/should be used? I absolutely agree that in an > ideal world this issue should not be externalized yet here we are. This is > why I made the point above that lists should respect DMARC policy and not > accept submissions from domains with DMARC p=reject policies. It becomes "Not > your circus and not your monkey". and forces the problem back to the domain > and it's users. If an MLM isn't modifying the message then the DKIM signature > should survive and this discussion is irrelevant. I think this covers the > range of MLM use cases that have been a topic of discussion. If the MLM admin > really wants to poke those domains publishing p=reject then they can respond > to user subscribe attempts or submissions that are rejected with an > explanation that they need to go have a meaningful discussion with their mail > admin/IT staff/domain account provider or whoever is responsible for > publishing p=reject for tht domain but still allowing users to sign up for > MLMs or attempt to use other intermediaries. popcorn is of course optional. > > Michael Hammer > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise [email protected] (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
