DMARC: Users cannot send emails via a wiki's [[Special:EmailUser]]

Assigned To
Platonides, Trijnstel, NQ and 25 others
"The World Burns" token, awarded by Technical13."Like" token, awarded by Xaosflux.

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:, even if it's allowed from an SPF point of view (i.e. ' via'). 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 for more info on issue 2).

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

Version: wmf-deployment
Severity: normal
See Also:

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz64795.
valhallasw created this task.Via LegacyMay 3 2014, 12:40 PM
Nemo_bis added a comment.Via ConduitMay 3 2014, 12:51 PM

How is this a Wikimedia bug? Is there any workaround? Seb35 hinted yes:

(In reply to Seb35 from comment #22)

could [...] implement[...] DMARC(+DKIM+SPF) on to
improve delivrability for this bug, *BUT* this could lead to heavy
consequences on other emails (like non-delivery) so it must
be carefully thought before action.

Anyway, if working around this requires special DNS settings something should (also) be done in core.

valhallasw added a comment.Via ConduitMay 3 2014, 12:55 PM

At the very least, it's good to have a place to keep track of the issue, even if we don't intend to solve it ourselves.

Secondly, there are some options for working around this in Mediawiki;

  1. by blocking Yahoo users from using Special:SendEmail, or
  2. by changing the SendEmail sender to, and adapting Reply-To (not sure if this works), or
  3. 2), but by letting people reply through the wiki.
scfc added a comment.Via ConduitMay 3 2014, 7:22 PM

It would be nice if these deficiencies for Yahoo! users were also noted prominently on the sign-up pages and not only show up on Special:SendEmail & Co. so that users can reconsider their choice of mail provider /before/ being handicapped.

Seb35 added a comment.Via ConduitMay 4 2014, 11:13 AM

I removed the "mailing lists" issue from this bug since it is a different software, different domain, and sort of different email function ("relay" vs "original on behalf of"); created bug 64818 for this.

As a resume of the proposed solution above, there are three solutions (at least):
(1) a quick one: set Wikimedia’s $wgUserEmailUseReplyTo to true. This would apply for all users, kind of functionality loss for me since the user no longer see who is the "sender".
(2) a more robust one: patch MediaWiki to decide on a domain-by-domain basis if $wgUserEmailUseReplyTo should be used. Yahoo and AOL would fall into the first case, others not. This would add inconsistency from an user to another, and hence a bit more difficult to document and explain to users.
(3) a radical one: patch MediaWiki to blacklist some domains from sending user-to-user emails and add a warning if users use such domains.

Seb35 added a comment.Via ConduitMay 4 2014, 11:39 AM

I don’t think (3) is a good solution since it’s a loss of functionality for DMARC senders and it would add as much code as (2).

Between (1) and (2) and status quo, it depends if:

  • we want show Yahoo, AOL, and other DMARC email providers that DMARC should not be still used → status quo (DMARC senders think they could send emails throught MediaWiki although they couldn’t – I don’t know if the sender of a user-to-user email is warned if the email don’t reach the destination)
  • we think DMARC is a rather bad solution but we want to mitigate it and we don’t want to penalise non-DMARC senders, and we think DMARC will not be widely implemented as it is currently (still not an IETF RFC) → solution (2)
  • we think DMARC will be widely implemented in the near future (without proper solution to send an email on behalf of somebody), or we want a quick and/or transitional solution → solution (1)

I feel the more conservative approach would be to choose (1) and see how things evolve, particularly given DMARC is not really standardised as of now and only a big-scale experiment by Yahoo and AOL.

Nick added a comment.Via ConduitMay 29 2014, 1:24 PM
  • Bug 65860 has been marked as a duplicate of this bug. ***
Technical13 added a comment.Via ConduitJul 14 2014, 7:27 PM

Has anyone considered allowing editors to connect directly to Yahoo SMTP servers, or contacting yahoo at to discuss authentication and configuration options?

bzimport added a comment.Via ConduitAug 11 2014, 2:32 PM wrote:

I assume it would be wise to globally let users know that they can't send email through their yahoo mail. it could be a message in Special:SendEmail.

bzimport added a comment.Via ConduitAug 16 2014, 9:12 PM

moschris wrote:

In response to Nemo, it is a Wikimedia bug. It's spoofing a From address. The user's email address shouldn't be used for this - using reply-to is quite adequate. And for the record, Gmail has also been flagging these emails as 'suspicious' for the last few months. So it wouldn't be surprising if they started rejecting them altogether.

valhallasw added a comment.Via ConduitAug 16 2014, 10:25 PM

That's a different (but equally valid) issue (SPF vs DMARC). The SPF issue can be solved with sender rewriting. I'm surprised that hasn't been implemented yet, to be honest.

Switching to a '' sender + reply-to header would solve both issues in MW, I think, and it should be a fairly simple change -- although it would require a new configuration variable for the new sender.

Nemo_bis added a comment.Via ConduitSep 17 2014, 9:04 AM
  • Bug 70930 has been marked as a duplicate of this bug. ***
Aklapper added a comment.Via ConduitOct 22 2014, 4:32 PM
  • Bug 72363 has been marked as a duplicate of this bug. ***
Technical13 changed the title from "DMARC: Users cannot send emails via a wiki (from Yahoo addresses etc)" to "DMARC: Users cannot send emails via a wiki's [[Special:EmailUser]]".Via WebDec 26 2014, 10:04 PM
Technical13 set Security to None.
Jgreen added a project: Mail.Via WebJan 8 2015, 5:58 PM
Xaosflux added a subscriber: Xaosflux.Via WebJan 31 2015, 2:46 PM
Paine_Ellsworth added a subscriber: Paine_Ellsworth.Via WebFeb 2 2015, 2:56 AM
Jalexander added a subscriber: Jalexander.Via WebFeb 3 2015, 10:40 PM
Jalexander added a subscriber: Jgreen.Via WebFeb 3 2015, 11:38 PM

Given the privacy aspects of this I think we may want to switch the reply-to config for now as, at least, a stop gap measure. I've added operations and Jeff Green specifically given his experience on email for thoughts.

Xaosflux awarded a token.Via WebFeb 4 2015, 5:08 AM
Jgreen added a comment.Via WebFeb 4 2015, 5:57 PM

DMARC/DKIM/SPF and other specific technologies aside, the long-standing trend is for organizations to take responsibility for how their domains are used, and to control where messages can originate. It's oddball behavior to originate mail 'from' an address/domain that isn't local. Even for email clients this isn't the norm--typically a client relays through the mail provider's mailserver after authentication. This mediawiki behavior will only become increasingly difficult to support.

I think we should do the reply-to scheme, and include wiki user name as a comment in the header From line, like phabricator does:

From: Jgreen <>

Also short term we should create/use an address that bounces back with an informative message, like:

Sorry, your message could not be delivered. Please resend using the Reply-to address. For more information see

Long term we should consider adding a remailer. That way if people reply to the From address we can relay to the Wiki user instead of rejecting the message.

PleaseStand added a subscriber: PleaseStand.Via WebFeb 8 2015, 7:40 AM
Jalexander added a comment.Via WebFeb 12 2015, 9:35 AM

I'd really like to get this moving if possible, I'm starting to get more and more complaints both at the privacy mailing address (the biggest concern is the bounce back problems) and elsewhere. What are the next steps that we need to do to switch to the reply-to scheme?

Technical13 awarded a token.Via WebFeb 12 2015, 12:14 PM
Krenair added a subscriber: Krenair.Via WebFeb 14 2015, 4:54 AM
Krenair added a project: Security.Via WebFeb 15 2015, 6:11 PM
csteipp added a subscriber: csteipp.Via WebFeb 17 2015, 8:29 PM

I'd really like to get this moving if possible, I'm starting to get more and more complaints both at the privacy mailing address (the biggest concern is the bounce back problems) and elsewhere. What are the next steps that we need to do to switch to the reply-to scheme?

Someone from ops would need to setup whatever address we add. After that it should be a fairly simple config change. @Jgreen, is that something you can work on?

Aklapper added a subscriber: Aklapper.Via WebApr 29 2015, 8:22 AM

@Jgreen, is that something you can work on?

Jgreen added a comment.Via WebApr 29 2015, 12:13 PM

@Jgreen, is that something you can work on?

I'm pretty swamped with fundraising work at the moment, probably best to put it in the Tech Ops queue and see who has time to pick it up.

ori added a subscriber: ori.Via WebApr 29 2015, 5:43 PM

I added a EXIM alias, routed to :blackhole:.

TheDJ added a subscriber: TheDJ.Via WebApr 30 2015, 5:43 PM

The setting that needs to be changed is $wgUserEmailUseReplyTo

This variable changes the behavior in SpecialEmailuser.php and then it reuses the email address of $wgPasswordSender. This emailaddress is used by various systems, and judging from my mailbox, wgPasswordSender, it is currently configured to be

I'm not sure why we concluded we needed another no-reply emailaddress, but if we want to actually use it, it seems to me we would have to make a code change.

I do note that we have the $wgNoReplyAddress variable, which I actually think is a better variable to use in these cases. This variable seems to only be used by watch list enotifs ?

I do note that this is configured by default to reply@not.possible, which with the new top level domains is actually probably no longer a good idea...

TheDJ added a comment.Via WebMay 1 2015, 7:28 AM

Because I was trying to figure out what needed to be done to fix this ticket, I realized that it is rather messy area of MediaWiki, so I opened T97708.

Technical13 added a comment.Via WebMay 1 2015, 9:28 AM

@TheDJ does that ticket now block this one?

TheDJ added a comment.Via WebMay 1 2015, 5:11 PM

@Technical13 No. As far as I can see I think all that needs to be done is to flip wgUserEmailUseReplyTo and emails will be sent using the address.

revi added a subscriber: revi.Via WebMay 28 2015, 12:24 PM
Reguyla moved this task to Special pages on the Wikimedia-General-or-Unknown workboard.Via WebJun 16 2015, 2:09 PM
Elitre added a subscriber: Elitre.Via WebOct 7 2015, 4:03 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptVia HeraldOct 7 2015, 4:03 PM
NQ added a subscriber: NQ.Via WebOct 7 2015, 4:57 PM
Trijnstel added a subscriber: Trijnstel.Via WebWed, Nov 4, 3:59 PM
Platonides added a subscriber: Platonides.Via WebMon, Nov 23, 11:45 PM

Add Comment