Am 15. August 2019 um 02:08 Uhr +0900 schrieb Stephen J. Turnbull:
That doesn't help you one bit with your "rejection with no reason" problem, though. It helps you with one specific reason (DMARC p=reject).
I don't have that problem anymore since I pay for my SMTP relay provider. For me, the issue is solved. Before my personal mail (I'm not talking about mailing lists, just simple direct e-mail) was pretty much always sorted into the recipient's spam folder or directly rejected at the SMTP level (this was the case with both Microsoft and AOL; GMail usually filed my e-mail als spam). I looked up the reasons they gave in the SMTP reject; it was always bad reputation of IPs. Tools like mail-tester on the other hand say my e-mail and IP was fine, and delivery to small providers always went nicely. My mail server has never sent a single spam e-mail. I run it since years, and I am very sure that this never has happened. This mail server only hosts my and my family's e-mail.
I have no AOL contacts anymore, so I left that is it was. For Microsoft (i.e. outlook.com), I went through their IP unblocking formula (which at the time contained a CAPTCHA that I'm sure a computer could solve better than me simple human) multiple times, and I received "conditionally mitigated" as a response each time. After a few months, the rejections would start again.
Thus, I say they were rejecting my e-mail for no reason. Might be a hyperbole, but from my point of view, there was no reason. Again, the problem is now past with my workaround, so there is no need to investigate any further. I've given up on it. I don't believe you can have a VPS that directly delivers e-mail to the large providers successfully. The workaround with the SMTP relay provider still allows me to self-host, which fulfills my needs.
The answer to that is "why shouldn't they?"
I hope it goes like that.
I've never had a problem with any of the big services. There are reasons why some hosts might have problems due to no misbehavior of their own, and they wouldn't necessarily know about them either. But mostly the mail does go through.
Lucky you. My experience was the complete contrary, and it's not just me. Take a look: <https://lobste.rs/s/lvajly/google_is_eating_our_mail>
If the mail itself gets through, I see no reason why they wouldn't trust your ARC fields, so you won't get DMARC rejections, as long as nobody downstream of you breaks your ARC signatures.
So, my situation currently is this. I have no (public) mailing lists on my own mail server, so there is no need for DMARC or ARC. Then, I'm involved in an open-source project that does have a mailing list and I'm considering to add ARC support for the list (one of the reasons why I constantly read this very mailing list). The project is small, so we'd like to avoid any effort that is fruitless anyway. Finally, I moderate the German ruby-de mailing list without any kind of influence on the software stack running it. That mailing list server runs Mailman 2.1.15 and this is not something I have any influence on.
All of these list servers currently do not do ARC, hence I've not seen any rejections of ARC-signed messages (as there are none). I'm only evaluating how likely it'd be to see them. Please don't get me wrong; I appreciate all the effort that went into ARC! It looks like a good solution to the DMARC problems.
If you're seeing something different (ARC-authenticated messages getting rejected for DMARC alignment failure), let us know and I'll talk to a guy who knows this gal.
This is a nice move. Thank you for this offer. When that happens, I'm going to post here!
But the day-to-day tuning of algorithms is targeted at users with mailboxes, not the lists that fill those mailboxes.
I am aware of that. See, when DMARC was spread over the world, ARC was not available. Even the Mailman wiki itself said and still says that DMARC has "negative consequences for mailing lists" and is "breaking long established mailing list norms, standards, and behaviors."[1] The problem still exists. On the ruby-de mailing list I moderate, there was a problem with a person sending e-mail from a p=reject domain to the list[2] (which is, remember, run by Mailman 2.1.15). Two subscribers were force-unsubscribed for the DMARC bounces. I had to manually re-subscribe them and had to explain the p=reject problem to the person sending the e-mails. This was... frustrating. And I think my statements on DMARC show my frustration.
Last I heard the Google folks and the IETF are very happy with ARC.
I appreciate it. I hope it solves these problems. It's just that I'm reluctant to believe there's a quick solution available. It sounds to good to be true.
because it is simply unfeasable to manually maintain a list of all open-source project mailing lists in the entire world. I could set a new one up tomorrow, how should you know?
That's not how this works.
I'm afraid it does. Fastmail does it exactly like that: manual white list, see <https://www.fastmail.com/help/technical/senderauthentication.html>. Quote of the relevant passage:
Until the list of ARC enabled forwarders grows we maintain lists of known good email forwarders and mailing lists, which we use to whitelist known-good mail forwarders, and apply this list when evaluating DMARC policies for inbound mail.
To do them justice, they say a little further down that a failed DMARC check at a p=reject policy domain does not cause an actual reject, but only increases the spam score. What worries me is that other providers might go that whitelisting approach, but don't follow the second part and still obey p=reject.
If everything goes well, nobody is going to do that and ARC is successful. I'm all in for that result, but I lack the knowledge to judge what is likely and what not. Which is why I'm asking here. From your answer, I see that you think such behaviour is unlikely. That's good news, and it answers my question. Thanks!
[1] https://wiki.list.org/DEV/DMARC [2] See July archive: https://lists.ruby-lang.org/pipermail/ruby-de/2019-July/thread.html
-- Blog: https://mg.guelker.eu