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

Assigned To
None
Priority
High
Author
valhallasw
Subscribers
csteipp, Krenair, PleaseStand and 16 others
Projects
Tokens
"The World Burns" token, awarded by Technical13."Like" token, awarded by Xaosflux.
Reference
bz64795
Security
None
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: someone@yahoo.com, even if it's allowed from an SPF point of view (i.e. 'someone@yahoo.com 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.


Version: wmf-deployment
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56414
https://bugzilla.wikimedia.org/show_bug.cgi?id=59731

bzimport added a subscriber: wikibugs-l.
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 wikimedia.org to
improve delivrability for this bug, *BUT* this could lead to heavy
consequences on other @wikimedia.org 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 noreply@wikimedia.org, 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 dmarc-help@yahoo-inc.com to discuss authentication and configuration options?

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

mardetanha.wiki 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 'noreply@wikimedia.org' 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 WebSat, Jan 31, 2:46 PM
Paine_Ellsworth added a subscriber: Paine_Ellsworth.Via WebMon, Feb 2, 2:56 AM
Jalexander added a subscriber: Jalexander.Via WebTue, Feb 3, 10:40 PM
Jalexander added a subscriber: Jgreen.Via WebTue, Feb 3, 11:38 PM
Jalexander added a project: operations.

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 WebWed, Feb 4, 5:08 AM
Jgreen added a comment.Via WebWed, Feb 4, 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 <no-reply@phabricator.wikimedia.org>

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 https://wikipedia.org/some-helpful-page

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 WebSun, Feb 8, 7:40 AM
Jalexander added a comment.Via WebThu, Feb 12, 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 WebThu, Feb 12, 12:14 PM
Krenair added a subscriber: Krenair.Via WebSat, Feb 14, 4:54 AM
Krenair added a project: Security.Via WebSun, Feb 15, 6:11 PM
csteipp added a subscriber: csteipp.Via WebTue, Feb 17, 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?

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.