Fix 550 Empty envelope senders not allowed
Problem reported by Ron Raley - 12/18/2023 at 11:26 AM
Our user is sending email and the return path is blank. Can someone let us know how to fix this for the user?  Here are the details of the issue.

This MIGHT be a Read Receipt.  I can't confirm just yet.

The recipient has an Exchange Server and returning the following:
Remote Server returned: '550 Empty envelope senders not allowed'

Here is the outgoing SmarterMail message header:
Return-Path: <>
Received: from Speedy (d-72-28-130-31.md.cpe.atlanticbb.net []) by mail.firehousesolutions.com with SMTP
    cipher=Aes256 bits=256);
   Mon, 18 Dec 2023 10:12:34 -0500
From: *********************
To: *******************
In-Reply-To: <350ad67b03d54d70a7b5d1d3fc07d80c@stmaryscountymd.gov>
Subject: Read: Pager List
Date: Mon, 18 Dec 2023 10:12:33 -0500
Message-Id: <00b601da31c4$a0ea4670$e2bed350$@lpvrs.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLaBv0V1EyCZ6EGUw6IHyH/ILqKswJ8xyCrAO8EgMWulBzWhA==
X-Antivirus: AVG (VPS 231218-4, 12/18/2023), Outbound message
X-Antivirus-Status: Clean
Content-Type: multipart/report;

4 Replies

Reply to Thread
Andrew Barker Replied
Employee Post
Based on the headers you provided, this message does appear to be a Message Disposition Notification (MDN) - specifically a read receipt. It also looks like this message was originally generated by an Outlook client. I did a quick test and was able to replicate this behavior using an IMAP account in Outlook. Basically, it looks like Outlook is submitting the MDN message to SmarterMail over SMTP. As part of the submission, Outlook is providing the empty Return-Path, which SmarterMail uses when sending the message to the remote server.
Andrew Barker Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
Ron Raley Replied
Andrew, I appreciate your assistance.  In doing some research, it looks like the MDN Return-Path should be null <>.

This is from RFC 2298

"The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be null (<>), specifying that no Delivery Status Notification messages or other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN."

Does this mean that the recipient Exchange server is too strict to allow any Message Disposition Notifications (MDN)?  So the recipient system isn't really accepting any of them.  Do you agree?
Andrew Barker Replied
Employee Post
Yes, that is my understanding. They will also have the same issue receiving any Delivery Status Notifications (DSN), as those have a similar restriction mentioned in RFC 3461:

The DSN sender address (in the SMTP MAIL command) MUST be a null reverse-path ("<>"), as required by section 5.3.3 of [RFC 1123].
Andrew Barker Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
Douglas Foster Replied
Most systems will accept messages with null sender, but of course every system is able to choose their own policies.   Recently, my system has been flooded with null sender spam, which I have been able to contain without blocking all null-sender messages.   Apparently the organization in your post has decided to just block everything with null sender.

Those RFC numbers have been updated.   You should use RFC 5321 as a reference as a starting point for everything related to SMTP and RFC 5322 as the starting point for everything related to message format.   Without re-reading the RFCs myself, I believe that use of null sender is currently considered preferable, but not mandatory.   I have recently observed automatic replies with both null sender and vallid sender, depending on the source and reply type. 

Reply to Thread