Page MenuHomePhabricator

Email server's DMARC config prevents users from sending emails via Special:EmailUser
Closed, ResolvedPublic

Description

Yahoo recently changed their DMARC configuration, which has two results that are relevant for us:

  1. It's no longer possible to send e-mails From: [email protected], even if it's allowed from an SPF point of view (i.e. '[email protected] via wikipedia.org'). This means Yahoo users cannot send e-mail from the wiki anymore.
  1. It's no longer possible to change parts of an e-mail (e.g. the subject to add a mailing list name) sent by a Yahoo user. This means Yahoo users cannot send e-mail to a mailing list anymore. If they do try to, they will receive a flood of error mails from mail servers rejecting the e-mail.

See http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html for more info on issue 2).

For issue 1), we might want to block Special:SendEmail for people with a @yahoo.com address, telling them their e-mail will not be delivered.


See Also:
T58414: Get mail relay out of Yahoo! blacklist: apply to Yahoo for whitelisting bulk mail
T61731: mailman emails taking long time for delivery, getting stuck in sodium

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Why are these email bug reports not being dealt with? One suggestion, that huge groups of people get told that special:email is broken for them, is just unacceptable. The solution is trivial:

For users with problem email providers, send the email as though it came from MediaWiki just the same as all the notification emails I currently get. And just stick the sender's email address in the subject or as the first line of the email -- it's a plain-text email anyway so formatting it to add an extra line is easy.

This is the work of an hour or so. Please. I shouldn't have to change my email provider in order to use MediaWiki, and I'm not sympathetic to the whole "spoofing the sender" thing you did anyway.

Change 322243 had a related patch set uploaded (by Legoktm):
Set $wgUserEmailUseReplyTo = true;

https://gerrit.wikimedia.org/r/322243

r322243 will possibly fix this for Wikimedia, by changing the sender address to the same one used by the wiki itself (which we know works) but sticking the sending user's email address into the reply-to field.

However, that will not fix the issue completely. If I am a non-WMF user of MW, I have no way to know about this issue or the possible fix for it. Therefore, I am going to also assign this task to MediaWiki, and I hope it is kept open until the latter concern is addressed, may it be through documentation change, adding it to the list of "known issues", or even changing MediaWiki code such that it defaults to using reply-to when certain conditions are met.

Another thought:

If an email is tried to be sent a few times and it bounces (as appears to be the case here when the sender is a Yahoo! address) and $wgUserEmailUseReplyTo is false, I think what should really happen is MediaWiki should return the email to the sender (i.e. an email from [email protected] to that Yahoo! address) and say "MediaWiki was unable to send this message, because it boucned. It appears that your email server may not allow MediaWiki to send emails on your behalf; please use a different email provider, or notify your wiki admins to enable the $wgUserEmailUseReplyTo option".

I think this should be incorporated into Extension:BounceHandler. I am proposing this, because then non-WMF wiki's would have a way to know what to do when emails don't go through (... at least as long as they also use Extension:BounceHanlder).

Huji renamed this task from DMARC: Users cannot send emails via a wiki's [[Special:EmailUser]] to Email server's DMARC config prevents users from sending emails via Special:EmailUser.Nov 27 2016, 12:13 AM

Change 323672 had a related patch set uploaded (by Legoktm):
Set $wgUserEmailUseReplyTo = true; on group0 wikis

https://gerrit.wikimedia.org/r/323672

Change 323672 merged by jenkins-bot:
Set $wgUserEmailUseReplyTo = true; on group0 wikis

https://gerrit.wikimedia.org/r/323672

Mentioned in SAL (#wikimedia-operations) [2016-12-01T01:48:00Z] <legoktm@tin> Synchronized wmf-config/InitialiseSettings.php: Set $wgUserEmailUseReplyTo = true; on group0 wikis - T66795 (duration: 00m 46s)

The proposed fix is now live on test wikis and mediawiki.org. Here's what the emails now look like:

To: Legoktm <[email protected]>
Subject: Wikipedia email from user "Legoemailtest1"
From: Wikipedia <[email protected]>
Reply-To: Legoemailtest1 <[email protected]>

From is now set to Wikipedia, but the Reply-To is the account I sent it from. If you've had issues sending emails in the past feel free to send me test emails from test.wikipedia.org and I can let you know if they've been received. In about a week I'll be deploying this to all wikis for all users pending everything goes well.

Should From be Wikipedia <[email protected]> or something like either Legoktm <[email protected]> or Wikipedia on behalf of Legoktm <[email protected]>? I am asking because from is what will show up in your inbox, and if it is always "Wikipedia" it may not be super useful.

This comment was removed by Xaosflux.

Perhaps something like [email protected] and include which project generated the mail? Examples:
[email protected]; [email protected]; etc./

Then if there is a abuse from a project - you will know which project admins need to revoke email access form a user.

The problem here is that usernames are case-sensitive and allow more characters than email addresses. It can't work if there's no simple 1:1 mapping between them.

Perhaps something like [email protected] and include which project generated the mail? Examples:
[email protected]; [email protected]; etc./

Then if there is a abuse from a project - you will know which project admins need to revoke email access form a user.

The email footer will still say "This email was sent by Legoemailtest1 to Legoktm by the "Email this user" function at Wikipedia." at the bottom.

Maybe the footer needs work too - that doesn't tell you if it came from say enwiki, eswiki, dewikibooks, etc

Maybe the footer needs work too - that doesn't tell you if it came from say enwiki, eswiki, dewikibooks, etc

Do you want to split that into a separate task then? I don't really see how it's related to this task as the current emails don't include that information anyways.

The last few suggestions are only tangentially relevant. Let's not stall this task with scope creep.

I just realized something... As emails will now appear to be sent by Wikimedia, it might be less clear to people that by reply'ing, they will disclose their own email address...

That might be problematic...

Screen Shot 2016-12-01 at 17.37.04.png (485×546 px, 39 KB)

I just realized something... As emails will now appear to be sent by Wikimedia, it might be less clear to people that by reply'ing, they will disclose their own email address...

That might be problematic...

Disclosing you email address while replying to an email in an email provider or software, is that not the usual behavior?

The point is that they'll be disclosing to an address other than the sender (wikimedia). But I agree this is a non-issue

I think the footer should be expanded to also say "by replying to this email, you will be disclosing your email address to the original sender of this message".

I am totally fine with updating the footer message to make it clearer that you're revealing your own email address, but I don't consider it a blocker to this task - it should be split to a separate one.

I'm aiming to deploy this everywhere tomorrow (that way T152242 will have been deployed everywhere too)

Change 322243 merged by jenkins-bot:
Set $wgUserEmailUseReplyTo = true; everywhere

https://gerrit.wikimedia.org/r/322243

Mentioned in SAL (#wikimedia-operations) [2016-12-08T22:03:10Z] <legoktm@tin> Synchronized wmf-config/InitialiseSettings.php: Set $wgUserEmailUseReplyTo = true; everywhere - T66795 (duration: 00m 56s)

Change 326044 had a related patch set uploaded (by Legoktm):
Set $wgUserEmailUseReplyTo = true by default

https://gerrit.wikimedia.org/r/326044

@Legoktm - I have tested it (ru wiki) - it works! =) Thanks.

A user at FA WP also just tested it with a Yahoo! sender address and it worked. No surprise, of course, because Yahoo! email servers were not involved at all.

@Legoktm - I have sent 3 emails with copy to me. Two of these emails I have sent to me.

After 10 minutes I have received 0 emails and 0 copies. The correct result should be 3 copy and 2 emails. Its on ru wiki.

Any explanations?

@Legoktm - after some time of tesing - it doesnt work.

If I send the emails to me - its ok.

If I send to other users - I receive the copy of my message (email) and the user receive the notification in wiki. This notification said that I have sent the email but he got no email. :(

@AnnaMariaKoshka: Feel free to create a separate task with more information that allows investigation. I assume the user checked their spam folder?

I changed the email address on one of my accounts (one I use when I give presentations and don't want to log in with my normal account on unknown computers) to a Yahoo address and failed to replicate the problem; both sending and receiving worked fine.

Change 326044 merged by jenkins-bot:
Set $wgUserEmailUseReplyTo = true by default

https://gerrit.wikimedia.org/r/326044

Change 378848 had a related patch set uploaded (by Kghbln; owner: Karsten Hoffmeyer):
[mediawiki/core@REL1_27] Set $wgUserEmailUseReplyTo = true by default

https://gerrit.wikimedia.org/r/378848

Change 378851 had a related patch set uploaded (by Reedy; owner: Legoktm):
[mediawiki/core@REL1_27] Set $wgUserEmailUseReplyTo = true by default

https://gerrit.wikimedia.org/r/378851

Change 378848 abandoned by Reedy:
Set $wgUserEmailUseReplyTo = true by default

Reason:
Proper cherry pick done in https://gerrit.wikimedia.org/r/378851

https://gerrit.wikimedia.org/r/378848

Change 378851 merged by jenkins-bot:
[mediawiki/core@REL1_27] Set $wgUserEmailUseReplyTo = true by default

https://gerrit.wikimedia.org/r/378851