mails relayed from lists.tpo to gmail.com bounces

added component::internal services/service - lists owner::qbi priority::medium severity::normal status::assigned type::defect labels

I don't see where lists is relevant here.

Also, AIUI, this email was sent with an envelope From whose SPF record asks for the mail to be rejected.

Replying to weasel:

I don't see where lists is relevant here.

Also, AIUI, this email was sent with an envelope From whose SPF record asks for the mail to be rejected.

Ok, so the extra information and bounce is probably only btb here.

The original issue is that tor-announce mail is not making it to gmail.

That's probably because the tor-announce list is configured to mess with both subject and body. It should stop doing that.

right, i think I have actually fixed my own specific problem, with your help. the problem was indeed that the Envelope-From was incorrectly mapped to my own email address. The fix was to simply change my email client to use the From: header to generate the envelope-from. In my case (notmuch-emacs), that meant the following customize settings:

 '(mail-envelope-from (quote header))
 '(mail-specify-envelope-from t)

That said, I do believe we have delivery problems to gmail in general, and I think the original report from that user should be considered as such, even though we don't have many details.

Sorry for the noise...

so we had another report of a problem occurring with gmail.com recipients today on the tor-internal@lists.torproject.org mailing list.

the problem was with the email Message-ID: <20190321172741.GB78672@vpn209009.nrl.navy.mil> which gmail refused with the following error:

Mar 21 17:27:53 eugeni/eugeni postfix/smtp[4376]: 6C5ECE0ED2: to=<[REDACTED]@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c00::1a]:25, delay=0.9, delays=0.03/0.22/0.15/0.5, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:400c:c00::1a] said: 550-5.7.1 Unauthenticated email from nrl.navy.mil is not accepted due to 550-5.7.1 domain's DMARC policy. Please contact the administrator of 550-5.7.1 nrl.navy.mil domain if this was a legitimate mail. Please visit 550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.1 DMARC initiative. j5si3735441wmh.102 - gsmtp (in reply to end of DATA command))

The email indeed comes from a domain with the following DMARC policy:

_dmarc.nrl.navy.mil.	1031	IN	TXT	"v=DMARC1; p=reject; rua=mailto:dmarc-reporting@dren.mil; ri=86400"

... an aggressive, but not unusual or invalid DMARC policy.

I'm not sure what the way forward is here, but I believe that a simple fix would be to enable the general/from_is_list setting to "munge" the From header to be the mailing list itself instead of the original sender. this is a controversial change, so a "lesser-evil" alternative might be the privacy/sender/dmarc_moderation_action setting which does that only for messages with a DMARC policy. But then we get inconsistent headers for the mailing list which might confuse filters and/or users.

since this is a little controversial, i'd like to consult with fellow TPAs before going ahead with any change.

for those who want to experiment with those changes, those are direct URLs for the tor-project@ mailing list:

https://lists.torproject.org/cgi-bin/mailman/admin/tor-project/?VARHELP=general/from_is_list https://lists.torproject.org/cgi-bin/mailman/admin/tor-project/?VARHELP=privacy/sender/dmarc_moderation_action

I'm fine with seeing us experiment with other options. Mail in general is getting unreliable on the internet these days, but that doesn't mean we can't slow down our eventual demise.

I think it might still be the case that mit.edu silently discards mailman confirmation mails. Now when I want to subscribe arma@mit to a Tor list, I log into the mailman web interface as admin and subscribe it directly. Otherwise I can never confirm my intent to subscribe, because I never get the mail inviting me to confirm.

Once a year or so, gmail decides to start bouncing all of the mails that come from a given list, e.g. tor-relays@lists.tpo. Our mailman, after a few messages to the list that all bounce from gmail, suspends the subscriptions of all gmail users on the list. Then we go through the horrible mailman web interface and un-suspend each of them.

There has been something going on with state.gov over the last few years, where mails from them to @tpo don't arrive.

And we should remember that @lists.tpo is a different system than @tpo.

So: experimentation good, but we should be sure to keep an eye on what other things get broken when we do our various tests.

Thanks!

thanks for the feedback, @arma. i've marked this ticket specifically about lists.tpo, to distinguish it from email forwarding or other problems.

and also note this is specifically about gmail.com and, so far, only about one specific domain (the .mil one) having a strict DMARC policy. we might want to open separate issues for other specific problems that could have other solutions.

Trac:
Summary: mails relayed to gmail.com bounce back to mails relayed from lists.tpo to gmail.com bounces

another such case:

550-5.7.1 Unauthenticated email from nrl.navy.mil is not accepted due to 
550-5.7.1 domain's DMARC policy. Please contact the administrator of 
550-5.7.1 nrl.navy.mil domain if this was a legitimate mail. Please visit 
550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about the 
550 5.7.1 DMARC initiative. 22si7281828wmj.11 - gsmtp (in reply to end of DATA command))

seems to me the list admins could simply flip the switch on the DMARC setting here.

@qbi, could you take a look at this? or some other listadmin?

Trac:
Owner: tpa to qbi

More background about the Mailman options is at https://wiki.list.org/DEV/DMARC

This seems to imply that dmarc_moderation_action is probably less disruptive, and also recommends avoiding setting from_is_list.

I haven't experimented with any of these myself.

it looks like the lists people are too busy to take care of this right now, so i'll see what i can do here.

Trac:
Owner: qbi to anarcat

note, related even if old: #19914 (moved)

sigh. i'm swamped, and since this might be a disruptive change, i'm going to push this back to my return from vacation, in january... sorry folks.

qbi has some cycles to handle this, reassigning.

i think the next step is to re-delegate this to the individual list admins and show them how to deploy those mitigations.

Trac:
Owner: anarcat to qbi

mentioned in issue #30608 (moved)

mails relayed from lists.tpo to gmail.com bounces

Child items ...

Activity