5

Background—the standards

RFC 5321 §4.5.5 states:

All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path.

For the avoidance of doubt, RFC 2119 §3 defines "SHOULD" as "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

Situation

The "particular circumstances" under consideration are where Alice does not wish to receive delivery status notifications (related to emails that she originated).

She has a few options:

  1. ignore/discard any such notifications when she receives it—clearly this behaviour would be entirely correct, but it's a nuisance (and a waste of her resources);

  2. refuse to accept such notifications at some lower level—arguably the reverse-path would no longer be "valid" (sadly not defined in the RFC) and, if so, such behaviour is contrary to the RFC's recommendations; or

  3. originate the email with a null reverse-path so that notifications never get generated in the first place—clearly contrary to the RFC's recommendations.

Questions

I'm pretty sure that these circumstances constitute a "valid reason" to ignore the RFC's quoted recommendation above—but I want to be sure that I've understood the "full implications" of options 2 and 3.

In particular, I note that:

  • Under option 2, some agents may detect that the reverse-path is not valid

  • Under option 3, some agents may treat mails with null reverse-paths as special cases

Either way, the agents might consequently refuse to accept/relay/deliver the email, or may use such information to increase the likelihood of its being flagged as spam. How common are such measures in practice?

Are there any other concerns/implications that I should consider?

Community
  • 1
eggyal
  • 392
  • 4
  • 16
  • 4
    So Alice doesn't want to know when her mail isn't going through? I can think of several reasons why that might be the case, but all of them are very bad. – Michael Hampton Apr 16 '15 at 17:41
  • @MichaelHampton: Alice is a webapp, and the emails are confirmations sent to site users when they submit certain webforms. Nobody cares if the messages don't deliver, and certainly no human will read or act on delivery status notifications if they are receieved. – eggyal Apr 16 '15 at 17:45
  • 1
    The usual solution to that is to set the from address to a nonexistent user. – Michael Hampton Apr 16 '15 at 17:46
  • @MichaelHampton: if by "from address" you mean the *envelope sender*, then that is identical to option 2 above is it not? – eggyal Apr 16 '15 at 17:47
  • And that is why you must carefully consider the implications of not knowing whether your site users' email addresses are valid. :) Besides, this will _also_ mask problems with _your_ email system. – Michael Hampton Apr 16 '15 at 17:49
  • @MichaelHampton: We are content with the implications of not *knowing* whether the mails were delivered. That is explicitly stated in the question. I am asking about wider implications of the suggested approaches, both on the *probability* of mail not being delivered and any wider concerns. – eggyal Apr 16 '15 at 17:52
  • @MichaelHampton: Indeed you have suggested using option 2, without addressing the explicit concerns with that approach mentioned in the question. – eggyal Apr 16 '15 at 17:53

3 Answers3

4

4 - handle the bounce.

Generally the best approach is to cause the bounce to go to some sort of bounce-handling process so that persistently bouncing recipient address can ultimately be pruned out of your database. Which could be a .forward for "alice", or adjusting the envelope sender to be a handler process.

Whether or not "alice" cares whether the email bounces, the recipient server administrators or filters often do. In many cases, recipient servers count every bounce as negative reputation points. Do it enough, and you end up on their blacklists and you won't be able to get anything through.

Don't chew up other people's resources because you're too lazy to handle it yourself.

Community
  • 1
Chris Lewis
  • 41
  • 1
  • Good points, but there's no database here—emails are only generated interactively in response to web user input/actions. I can't think of any way that we would modify our behaviour even if we learnt that one particular address was repeatedly bouncing. – eggyal Apr 26 '15 at 16:21
  • 1
    There's a couple of things worth mentioning - even addresses used this way have an unfortunate way to live on and/or cause problems. For example, a legitimate user could be entering in an address that filter-bounces or something (I have a friend who for some reason has people who think they own _his_ address and sign up their banks to it), and it would be good to identify who they are - eg: a user complaining they're NOT getting an email they expect. Worse, if someone uses your facility to spam or DOS someone. By /dev/nulling the bounces, you never will understand how well it's working. – Chris Lewis Apr 27 '15 at 19:38
  • Understood. But in this particular application, the emails are only a confirmation to the user (at an address that they enter) that an action has been performed. Their addresses are not stored, or used for any other purpose. Should they enter an incorrect address, then that address will receive their notification. Should the address they provide bounce, then there is nothing to be done but discard the bounce. We have other mechanisms in place to prevent abuse of our systems for amplification attacks. – eggyal Apr 27 '15 at 22:17
2

Using option #1 is always the better solution. Think of it like paper mail; a functioning return address is mandatory. Email is only getting more restricted (DMARC, etc) due to spamers taking advantage of the open policy. It's really not that hard to automate dealing with replys you don't care about. But likely less than 10% of email servers are that restrictive so you can probaby get away with it. Also be sure to avoid getting your server listed in a dnsbl.

The rules are lax most places (I can send an email that looks like it's from you which would invoke a sort of DDOS if I sent it to everyone and crafted it to bounce) Look at all the restrictions in Postfix if you want to know what rules might be in effect.

You can't have it both ways; do it properly (#1) or resign to being tagged spammer (by at least some). Google uses no-reply@google.com and that won't ever reach me because my mail server requires a verified sender. Google is the best at anti spam if they can't have it both ways I'm sure we can't.

user1133275
  • 195
  • 1
  • 11
  • It is also interesting that [the documentation for the exim command line](http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_exim_command_line.html) states of the `-f` option: "*an empty sender can be specified by any user, trusted or not, to create a message that can never provoke a bounce*"—this would, of course, implement option #3 in my question. That exim provides for such an option, despite being clearly being contrary to the RFC's recommendations, perhaps indicates that it's not such a terrible idea? – eggyal Apr 17 '15 at 09:57
  • 1
    Linux has a policy of permitting all kinds of horrific behavior, that's why we love it because it has no restrictions on your own box, try to mess with someone else and you will find it has a lot of options to make it hard for you. – user1133275 Apr 17 '15 at 15:17
  • You may be interested in my follow-up question: [Originating (non-critical) emails from a “less-trusted” host](http://serverfault.com/q/683574). – eggyal Apr 17 '15 at 15:53
  • Actually, whilst they use `no-reply@google.com` (or similar) as the *message*'s "From" address, Google set the return-path of their emails to perfectly valid addresses: e.g. `abcdefghijklmno-pqrstuvwxyz12.345@somehost.bounces.google.com`. – eggyal Apr 18 '15 at 09:30
  • typo now fixed. – user1133275 Apr 18 '15 at 12:22
  • not accepting _and_ handling messages sent to the reverse path is a gross violation of sender expectations and a gross violation of good neighbour behaviour. (regardless of whether those messages have an empty sender envelope address themselves, but _especially_ if they have an empty sender address) – Greg A. Woods May 14 '15 at 20:04
1

In general, I agree that #1 is probably the best solution, you can just discard any returns at the server. Install a .forward that sends messages to /dev/null. It's unlikely your bandwidth bill will hurt.

To the wider discussion as to whether you should care about messages not being delivered, I don't really know anyone processing their own returns at any scale, but services like SendGrid, MailGun, etc.. are great at this, they allow you to send via HTTP POST, they manage reputation for the IP space, and tell you about returned mail and complaints.

For your case that may not be key, but in general, I try to avoid managing my own mail delivery in production these days. So much can go wrong, and it can be such a huge distraction from other aspects of maintaining a large web stack.

Justin Alan Ryan
  • 51
  • 3