Hello,
I manage a few public Mailman 2 mailing lists. A contributor to one of the lists was recently removed because of bounces, and they reached out to us to understand why.
- This poster’s email domain is gmail.com. For this thread, we’ll say it’s xxxxx@gmail.com.
- I found the relevant DSNs that the Mailman bounce processor received.
- In all cases, the DSNs were from mailer-daemon@googlemail.com
- All DSNs had this as the reason:
Delivery to the following recipient failed permanently:
xxxxx@gmail.comTechnical details of permanent failure: 554.5.7.1 The user or domain that you are sending to (or from) has a policy that 554.5.7.1 prohibited the mail that you sent. Please contact your domain 554.5.7.1 administrator for further details. For more information, please visit 554.5.7.1 http://support.google.com/a/answer/172179 My initial read of the DSN was simply that some policy that xxxxx@gmail.com had set up on his Gmail account was rejecting copies of their own emails sent to the list, but I looked a little closer at the original headers in the DSNs.
- In all cases, the Delivered-To in the original headers section of the DSN was to a different email address. For this thread, we’ll say it’s foo@bar.com, where bar.com’s MX records are aspmx.l.google.com and the usual alts.
Would this mean that there’s some policy set by the bar.com admins in Google Apps rejecting xxxxx@gmail.com’s email? If that’s the case, shouldn’t the DSN say delivery to foo@bar.com failed permanently instead, since that’s the recipient? Or is Google ignoring the “delivery to the following recipient” part of the message and putting the sender’s email there to blame them for the delivery failure? (The first line of the 554.5.7.1 explanation suggests that it might be.)
As a list admin, it feels wrong to ding (and eventually auto-unsub) xxxxx@gmail.com because foo@bar.com sets some arbitrary policy. Is there anything that can be done in Mailman 2 to detect and ignore these cases or have the bounce count against foo@bar.com? Does Mailman 3 handle these cases any differently?
Thank you, Pete
BLUF: I think this is just normal Google stealth "from alignment" lossage, which Mailman 2 and 3 both handle as a special case, but here Google's ****age is masked by forwarding through foo@bar.com. Probably a one-off, and not something you can do much about except advise this user to post from foo@bar.com, not xxxxx@gmail.com.
If you're into long Uncle Ranty answers, read on, MacDuff.
Oh, hot damn, are you at *that* ARIN? Hat's off, if so. (Excuse me for all the scattered thoughts, it's 4 am and I shoulda slept hours ago. :-)
Pete Toscano writes:
I manage a few public Mailman 2 mailing lists. A contributor to one of the lists was recently removed because of bounces, and they reached out to us to understand why.
- This poster’s email domain is gmail.com. For this thread, we’ll say it’s xxxxx@gmail.com.
Friends don't let anybody post from Google. Or Yahoo! Unfortunately, being a friend costs you all your friends....
Delivery to the following recipient failed permanently:
xxxxx@gmail.comTechnical details of permanent failure: 554.5.7.1 The user or domain that you are sending to (or from) has a policy that 554.5.7.1 prohibited the mail that you sent.
Would this mean that there’s some policy set by the bar.com admins in Google Apps rejecting xxxxx@gmail.com’s email?
More likely this is the traditional (since 2014) DMARC abuse, with a PARTICULARY EVIL Google mail twist. DMARC is a (by design) anti-phishing protocol that allows "transactional sources" like your-bank.com that mail *directly* to you to tell your email provider "never under any circumstances accept mail from somebody@your-bank.com that doesn't bear a valid your-bank.com digital signature (aka "DMARC p=reject").
Providers like AOL and Yahoo! that leaked billions of their users' address books to spammers have abused it as an anti-spam policy. The problem with freemail providers doing this is that unlike a bank, they can't have a policy of not using their address to post to mailing lists -- which frequently do things that invalidate digital signatures. So they bounce, and when bounces accumulate, the *intended recipients* get disabled and eventually unsubscribed.
The particularly evil behavior of Google is that they do NOT publish a p=reject policy, BUT ENFORCE IT ANYWAY on many Google-managed mail domains (not limited to Gmail). Sufficiently recent Mailman knows about this for Gmail, but cannot know for random bar.com because forwarding through bar.com to Gmail is not public.
It's unusual that a poster gets unsubscribed for this. If I understand you correctly, the same user is xxxxx@gmail.com and foo@bar.com. If that is not true, then Google is just outright lying here, and because sometimes it will be the truth, I don't know what we can do about it, except advise list owners to ban @gmail.com addresses from posting, which ain't gonna happen.
If it is correct, then it's because *Gmail* has an arbitrary policy of rejecting *its own* email when sent through a mailing list that invalidates digital signatures (as almost all mailing lists do). Worse, its DNS publicly pretends it does not have that policy.
If that’s the case, shouldn’t the DSN say delivery to foo@bar.com failed permanently instead, since that’s the recipient?
Who knows? As Ernestine the BOFH didn't quite say, "Oh, Mr. Veedle, WE are Google. WE don't have to care."
Ironically enough, Now Playing is The Chicks' "I'm Not Ready To Make Nice".
As a list admin, it feels wrong to ding (and eventually auto-unsub) xxxxx@gmail.com because foo@bar.com sets some arbitrary policy.
That is very likely NOT what happened, as explained above.
Aside: I guess you weren't here for the AOL/Yahoo! debacle in April 2014? Far worse things than ding/unsub happened then. Imagine what happens if you're a business and your accountant is sending a few $100K of invoices with "From: stuf4u@yahoo.com" through a non-Yahoo MX and they all bounce and you don't know why or what to do about it ....
Is there anything that can be done in Mailman 2 to detect and ignore these cases or have the bounce count against foo@bar.com?
Not without (very risky) code changes. All you can do is set one of the DMARC policies to "munge from" and hope. We do the best we can, but we have no insight into internal Google operations. This has the distinct stench of some probie dev moving too fast and breaking things, but is could also be Google policy, or a GoogleGroups DOS attack on Mailman (I hear that a lot of people are sick of GoogleGroups and are moving to other platforms, mostly not Mailman sadly). Or it could just be foo@bar.com setting xxxxx@gmail.com in .forward.
Your guess is as good as mine, but WE don't really dare guess, if you see what I mean.
Does Mailman 3 handle these cases any differently?
AFAIK currently Mailman 3 doesn't handle them differently from Mailman 2 -- All Mailman 2 Users Hail Mark Sapiro! Unfortunately Mark is on vacation for a couple of weeks so authoritative answers on that will likely have to wait for his return.
I can say that as time goes on, the patches needed become more complex and eventually even Mark will give up on syncing, and concentrate on Mailman 3.
You seem rather well-clued. Independently of whether it will help you handle this problem, I recommend biting the bullet and migrating to Mailman 3 sooner rather than later. Or if you have more money than time, there's a consultant page on wiki.list.org. If you have even more money than that, you can talk to my employer, mark@siriusopensource.com. :-) But really, it's not (usually) difficult, and you can get our advice (priceless ;-) for the usual price (also priceless), as long as you're OK with mailing list lags. With a little planning, you can almost surely do the migration incrementally and reversibly -- mailing list lags rarely need impact your subscribers.
Steve
participants (2)
-
Pete Toscano -
Stephen J. Turnbull