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?

Improve this question
7
  • 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, 2015 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, 2015 at 17:45
  • 1
    The usual solution to that is to set the from address to a nonexistent user.
    – Michael Hampton
    Apr 16, 2015 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, 2015 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, 2015 at 17:49

3 Answers 3

Reset to default
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 [email protected] 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.

Improve this answer
6
  • It is also interesting that the documentation for the exim command line 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, 2015 at 9: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, 2015 at 15:17
  • You may be interested in my follow-up question: Originating (non-critical) emails from a “less-trusted” host.
    – eggyal
    Apr 17, 2015 at 15:53
  • Actually, whilst they use [email protected] (or similar) as the message's "From" address, Google set the return-path of their emails to perfectly valid addresses: e.g. [email protected].
    – eggyal
    Apr 18, 2015 at 9:30
  • typo now fixed.
    – user1133275
    Apr 18, 2015 at 12:22
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.

Improve this answer
3
  • 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, 2015 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, 2015 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, 2015 at 22:17
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.

Improve this answer
1
  • Please see my comment on @user1133275's answer.
    – eggyal
    Apr 17, 2015 at 6:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .