Sign up for Office 365
Learn more about Office 365
I'm trying to get postfix to relay to Office365. I have a DL set up so that the relay can send mail with the appropriate From: senders, however, there are cases where postfix sends the null sender (bounces, delivery status reports, etc) but every time it does so, Office365 rejects it with "550 5.7.1 Client does not have permissions to send as this sender"
Feb 8 23:43:07 jane postfix/bounce: 099CE26E88: sender delivery status notification: 415DF26E89
Feb 8 23:43:07 jane postfix/qmgr: 415DF26E89: from=<>, size=2241, nrcpt=1 (queue active)
Feb 8 23:43:07 jane postfix/qmgr: 099CE26E88: removed
Feb 8 23:43:07 jane postfix/smtp: warning: pod51019.outlook.com[220.127.116.11]:587 offered null AUTH mechanism list
Feb 8 23:43:18 jane postfix/smtp: 415DF26E89: to=<firstname.lastname@example.org>, relay=pod51019.outlook.com[18.104.22.168]:587, delay=11, delays=0.05/0/5.6/5.3, dsn=5.7.1, status=bounced (host pod51019.outlook.com[22.214.171.124] said: 550 5.7.1 Client does not have permissions to send as this sender (in reply to end of DATA command))
By RFC, Office365 should accept the null sender but it does not.
Postfix likewise does not let me rewrite the null sender (that I know of).
How do I add the null sender to a DL, or give it permission to send mail using this account?
Thanks for the feedback.
As per my test on Exchange 2010, it is supported when providing mail from as null:
220 APGCOSSLABEX10.apgcosslab.local Microsoft ESMTP MAIL Service ready at Thu, 1
4 Feb 2013 00:18:03 -0800
250-APGCOSSLABEX10.apgcosslab.local Hello [10.0.24.136]
250-AUTH NTLM LOGIN
250-X-EXPS GSSAPI NTLM
235 2.7.0 Authentication successful
250 2.1.0 Sender OK
250 2.1.5 Recipient OK
354 Start mail input; end with <CRLF>.<CRLF>
test from telnet
250 2.6.0 <bf0e81fe-7bbf-4788-9da6-08a100f15a74@APGCOSSLABEX10.apgcosslab.local>
[InternalId=120] Queued mail for delivery
However, if P2 address is different from P1 address then you will hit such error:
4 Feb 2013 00:24:11 -0800
550 5.7.1 Client does not have permissions to send as this sender
In Office 365, when we configured SMTP relay server using Office 365 email address as email@example.com, it is required sending out the email using the same account firstname.lastname@example.org authenticated with Office 365.
Based on the log shared by you, it looks like the error is received after end of data command so you hit the error just as shown in my 2nd test. Therefore, please check on your application to understand what P2 address is used and confirm whether it matches the Office 365 account you used to authenticate with Office 365.
1 out of 1 people found this post helpful.
As far as I know, Office 365 does not allow null sender.
Besides, Postfix is a third-party mail server that can be used to set up an SMTP relay for Exchange Server and Exchange Online. Currently, only specific versions of Postfix are supported to set up a relay with Exchange Online. You have to use Postfix 2.9 or a later version to set up an SMTP relay with Exchange Online.
For your reference:
How to set up an SMTP relay in Office 365
0 out of 1 people found this post helpful.
Yes. I am using Postfix 2.9.
I am unsure what "3rd party" means in the context of RFC compliance. I understand you are saying that Exchange Online is not RFC compliant?
Null sender is always used in notifications like NDR. In the current situation, SMTP relay used to send mails. This mail is a standard mail, so the mail must have a valid sender. Also, Office 365 must ensure that the mail from Office 365 is not a abuse mail.
There is no abuse mail. This is from an intranet that is entirely controlled by our IT dept. I need a way for NDRs and other notifications to get through so users (and administrators) can get notifications of bounces and other issues (such as postfix mail delivery status reports). Currently, all of those errors disappear. Again, by RFC, MTAs should be able to accept mail with null senders, or ALL reporting simply disappears, including notification that mail did not get delivered because Office 365 denied the sender.
I understand your assertion is that in order to protect from abuse, Office365 must violate RFC. As far as I know, this is unique to Office365, as all other MTAs (that I know of) can be configured to properly handle null senders.
What should I do to insure that NDRs and other errors get delivered somewhere?
I don't think DL can archive your target. It's a wrong way.
Your requirement can be fulfilled with Shared Mailbox simply and it is also why we need a Shared Mailbox in Exchange Online.
A shared mailbox is a mailbox that multiple users can open to read and send e-mail messages. Shared mailboxes allow a group of users to view and send e-mail from a common mailbox. They also allow users to share a common calendar, so they can schedule and view vacation time or work shifts. Why set up a shared mailbox?
Check this article and here you go:
Set Up a Shared Mailbox
I am not looking to "archive my target".
I'm trying to get Office365 to accept mail from a relay in an RFC compliant way.
There is no abuse mail to worry about. The relay is entirely internal and only relays mail from trusted machines.
The "null" sender is a valid sender. Reread the RFCs carefully. It exists to prevent backscatter. If a relay refuses to accept mail with a null sender, all bounce notices get dropped into the bitbucket; there is no way to know the mail was lost, or why, unless somebody is monitoring the logs. In addition, postfix uses the mechanism to generate delivery reports.
Not only that, requiring the use of DL (or static entry) for maintenance of a whitelist is extremely inflexible and inconvenient. Minimally, there should be an option to not require whitelist, or, even better, some sort of regex support.
Finally, you should at least be able to add subdomains to the whitelist, so that (for example) email@example.com and firstname.lastname@example.org do not have to be added to the DL.
Anybody out there actually know anything about SMTP?
These guys do, but they use postfix
The syntax shown in RFC-821 for the MAIL FROM: command omits
the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page
15). An empty reverse path MUST be supported.
Exchange supports RFC 2821 on topic 'Simple Mail Transfer Protocol'.
The using of NULL can be used for DSNs and MDNs. All other type of messages should be sent with a valid, non-null reverse-path.
"The using of NULL can be used for DSNs and MDNs."
Outlook365 refuses to deliver all mail that has a null sender. Please review my original post.
>Feb 8 23:43:07 jane postfix/bounce: 099CE26E88: sender delivery status notification: 415DF26E89
As you can see, it is a DSN
>Feb 8 23:43:07 jane postfix/qmgr: 415DF26E89: from=<>, size=2241, nrcpt=1 (queue active)
Sender is null
>Feb 8 23:43:18 jane postfix/smtp: 415DF26E89: to=<email@example.com>, relay=pod51019.outlook.com[126.96.36.199]:587, delay=11, delays=0.05/0/5.6/5.3, dsn=5.7.1, status=bounced (host pod51019.outlook.com[188.8.131.52] said: 550 5.7.1 Client does not have permissions to send as this sender (in reply to end of DATA command))
In order to troubleshoot this problem, I would like to collect the domain information. I have sent you a private message on this. It was responded in a private message with a subject of "Information Request".
Please go to the Your details section on the right side of the community site.
Click Private messages.
Click the subject title of the response to read the message.
You can reply by using the form in that display to provide the information requested.
Let me make sure I understand what parts are what:
By "P1" you mean the "Mail From:" sender after the HELO, before DATA
By "P2" you mean the "From:" sender as sent in DATA?
If that is the case, for most null sender mail from a postfix relay, P1 is "<>" and P2 is MAILER-DAEMON (generally sans a domainname)
Does this sound right?