Email submission service allows any From

While it might be a nice gesture to allow users of online services in general to chose the way to present themselves, we don't want to provide this on our email submission service. The way spam is fought today is not limited to what words are being sent, but also what server is sending them. And while we do authenticate submitters of email messages, we don't enforce what From: headers they put in.

We could use the postfix smtpd_sender_login_maps config option for mapping From addresses to user id's.

changed milestone to %improve mail services

added Backlog label

assigned to @anarcat

We could use the postfix smtpd_sender_login_maps config option for mapping From addresses to user id's.

i'm not absolutely certain that's the right setting, but if it is, it would be somewhere in ./modules/postfix/templates/main.cf.erb. you would also want to hack at ./modules/profile/manifests/postfix/submission.pp if you need to deploy a map.

i'm not absolutely certain that's the right setting

seems like the documentation on this is:

http://www.postfix.org/SASL_README.html#server_sasl_authz_envelope

it seems like the login_maps is insufficient, we also need reject_sender_login_mismatch in smtpd_recipient_restrictions:

http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch

also, looking at the login_maps docs, it seems like we need an exhaustive list of email -> username maps and i'm not sure that's going to work or scale.

(if we do need that full list, then we need a patch to userdir-ldap again. urgh.)

to reframe the problem here, we would like the following, in decreasing order of priority:

1. restrict "envelope from" (FROM in the SMTP session) to @torproject.org (and no subdomains)
2. restrict From: headers to @torproject.org
3. enforce a match between From: and "envelope from"
4. enforce "envelope from" to match SASL usernames

i think 1 can be done with the check_sender_access map. 2 is harder because it requires inspecting the body, something which Postfix doesn't do on its own: it needs an external milter. vrfydmn can do this (and is packaged in debian), and also enforce 3, that is rewrite the From to match the envelope from (or reject messages that don't).

step 4 is the hardest one. it doesn't seem like postfix enforces that by default. you can do a smtpd_sender_login_maps, but then you need to list all users, something which would need to be done in userdir-ldap or a cron job that runs next to it (ugh).

so i am considering letting go of that requirement. the impact of this is that authenticated users could be able to forge envelope-from and From headers to masquerade as other torproject.org users. they SASL username would still be visible in the Received headers, however, so such forgery would be detectable.

the main goal of this ticket is to limit the blast radius of a possible compromise of an SMTP AUTH account. typically, those accounts are used to send enormous quantities of spam. by forcing the original email address, we limit the damage slightly, by forcing outgoing email to really come from us. it keeps us from being used for phishing campaigns, for example. and step 4, for this, is not actually necessary, unless we're worried about people masquerading as (say) donate@torproject.org.

specifically, this came up while discussing #40586 where we noticed that Apple mail needs you to bind your SMTP configuration with an existing account (say my anarcat@example.com account) to register the Tor SMTP server (submission.torproject.org) which makes it so the existing account's email will go through tor's server (ie. i will send anarcat@example.com through submission.torproject.org).

that would be bad, for both us and the user, because their anarcat@example.com would bounce, and it would affect our reputation, because we'd look like an open relay.

so the first step (check_sender_access) would already be a simple and effective fix for that first problem. everything else is secondary, and more and more complex, so maybe we should just do that first step.

@linus expressed interest in dealing with this.

assigned to @linus and unassigned @anarcat

Based on good work by @anarcat here's a plan.

(NOTE: MAIL FROM, a.k.a. envelope sender, is part of the SMTP protocol, while From: header is the message header visible to the casual recipient of an email message.)

Goal: Enforce three things: 0. MAIL FROM == From: header; 1. @domain part of envelope sender matches @.*torproject.org; 2. user@ part of envelope sender equals authenticated SASL username

Suggested solution for goals 0 and 1: Use https://github.com/croessner/vrfydmn (which is packaged for Debian) with -f mapfile where mapfile is a postfix map file containing domain names. Only listed domains are allowed in From: headers and only if MAIL FROM == From: header.

I haven't found a way of solving goal 2 without using reject_sender_login_mismatch which requires smtpd_sender_login_maps which in turns requires a list of SASL user names allowed to send email. There is such a list on submission service hosts (/etc/dovecot/private/mail-passwords) but it seems like we consider it bad form to run a script from cron to build a postfix map file from the contents of this file.

it seems like we consider it bad form to run a script from cron to build a postfix map file from the contents of this file.

to expand on that: i'm a little weary of adding any more glue to this already quite complex project, which involved many patches to two different userdir-ldap projects.

i also made a slightly different goal set in #40587 (comment 2770611) (sorry!), which seems more progressive. and again, i'd suggest that we should just start with a simple check_sender_access map, because it's going to get us a trusted return-path header.

if we do care about From (and i think we will, maybe because of e.g. dkim replay attacks but i haven't reviewed that in detail), then we can use that trusted return-path with vrfydmn to cleanup the From as well (because that is DKIM-signed).

so short term: check_sender_access, longer-term, maybe, vrfydmn.

then, if we are really worried about user A@torproject.org impersonating user B@torproject.org, generate a smtpd_sender_login_maps. but that doesn't solve the fake From (although it does fix the fake return-path completely, something which check_sender_access only partly fix).

added Email label

added Icebox label and removed Backlog label

Should the plan be updated given the outcome of the decision on whether or not we should be hosting our own email?

the new proposal to outsource email services (#40798 (closed), TPA-RFC-31) has yet to be adopted so, technically, this is still relevant. but it's likely that this ticket (along with many others) will be closed when TPA-RFC-31 will be adopted...

update on this... #40798 (closed) (TPA-RFC-31), is on hold right now, TPA-RFC-44 is being discussed (#40981 (closed)). if adopted, it will make this issue relevant again.

mentioned in issue #41396 (closed)

mentioned in issue #40987 (closed)

marked this issue as related to #41889

mentioned in issue #41889