-1

Is it possible to specify a header in an outgoing mail (I'm using PHPMailer) that tells the receiving server that I do not want bounce or out of office replies back?

The use case is for verification emails during registration (i.e., check that an email address exists and that the registering user has access to it). I have not interest in getting bounce emails sent back to me.

Dr Ljotsson
  • 111
  • 1
  • 2
  • Wouldn't the bounces be useful for your use case of verifying email addresses? – Torin Jul 21 '18 at 12:37
  • Torin: Yes, but then I would have to retrieve and parse the bounce email. This particular functionality in my application doesn’t deserve that much effort. – Dr Ljotsson Jul 21 '18 at 12:43
  • 1
    With so many MTAs around, I don't think there is a universal indicator that bounces aren't wanted. Besides, any server that sends mail should be prepared to receive bounces. – Torin Jul 21 '18 at 13:00
  • Don't do that. Instead, set the return-path address to an email address that just deletes the emails. – Jenny D Jul 21 '18 at 14:19
  • Jenny D: Thanks! That would probably be the best solution. – Dr Ljotsson Jul 22 '18 at 06:29

2 Answers2

0

For bounces: If the receiving server supports the DSN ESMPT extension RFC 3461, you can set NOTIFY=NEVER as an option into the RCPT command:

RCPT TO:<user@example.com> NOTIFY=NEVER

If the server doesn't support the DSN extension, you are out of luck.

I don't believe this will work for OOO replies.

Community
  • 1
Sven
  • 98,649
  • 14
  • 180
  • 226
0

Bounces are send with an empty envelope sender in order to prevent the bounces from bouncing and potentially introduce a bounce loop.

You could do the same with your mails to prevent them from bouncing. In the SMTP transaction it would look like this:

MAIL From:<>

Though this is just about the most efficient way to prevent bounces it does have a couple of potential drawbacks.

The receiving end may see the use of an empty envelope sender on an email that isn't actually a bounce as a spam signal. Thus your email could end up being rejected or automatically trashed.

Most likely you do not deliver emails directly from your application to the MX of the receiving domain but rather through your an MTA run by yourself or a service provider of your choosing. This MTA will thus have to deal with the delivery failures and if it cannot bounce it may instead produce noisy logs.

The later problem can be avoided by delivering mails directly from your application to the MX of the receiving domain (notice that some hosting providers will block such traffic). By delivering mails directly like that means that delivery failures will be seen directly by your application.

Usually this is fast enough to use for interactive usage, thus when the user submits their email address you can immediately tell the user if the email address does not exist. Though keep in mind that though it is usually fast it is not unusual for this to take 5 seconds, which is enough that the user need to be shown some sort of progress indicator to know their input is being processed.

In case the receiving domain implements greylisting, you'd need to include retry logic which could cause the progress indicator to be visible to the user for minutes before they get confirmation. But without the progress indicator they'd still have to wait for minutes for the email to get through, so the progress indicator being shown for minutes would still be an improvement UI-wise.

Given the complexity of implementing all of this in the application most opt to just send the mail through an MTA and let the user deal with checking their email repeatedly until the email (hopefully) arrives.

kasperd
  • 30,455
  • 17
  • 76
  • 124