Thank you for your input Jackson. We already have the Delivered-To header 
filtered so unfortunateley this is not a cause for our issue.

And thanks for your answer Janos, I also think it is worth to investigate 
further espacially because our users are used to restore mails and since we 
switched to EXO seemingly 90% of all restores fail. I will definitely pursue 
this further and if I can't find any clues the only remaining option is of 
course to open an issue with Microsoft on this.

Von: Jackson Craig <>
Gesendet: Dienstag, 27. April 2021 15:59
An: 'Piler User'
Betreff: RE: Restore to O365 fails


Most likely not the culprit, but thought I would share anyway - just ignore
if you already know it isn't due to this - this is something I encountered
with trying to restore mail to mailboxes. Just pasting in my notes that I
took at the time:

"Some mail will not restore to mailbox, and you get a
forwarding loop for the user (note that you always get
a forwarding loop for bcc the archive blind copy, this is
OK just ignore the message. It stops the restored mail getting
added into the archive again anyway).

This happens because of the Delivered-To header. Postfix adds
this header, and as there may already be one there with the
same recipient, it thinks the restored mail is in a mail
loop and you get the error (and no mail).

The quick workaround is to add a header check for the user, e.g.:

/^Delivered-To: IGNORE

add this to /etc/postfix/header_checks on the mail server

Remember to postmap the file after editing it."

This email and any attachments are confidential to the intended recipient
and may also be privileged.  If you are not the intended recipient, please
delete it from your system and notify the sender.  You should not copy it
or use it for any purpose nor disclose or distribute its contents to any
other person.

-----Original Message-----
From: Martin Nadvornik <>
Sent: 27 April 2021 14:24
To: Piler User <>
Subject: AW: Restore to O365 fails

Hi everyone,

we also have the same or at least a similar problem. However not with every
mail but with most. We were so far also unable to find the root cause for
this and can't see any distinctive differences between mails that fail to
restore and those that don't. In our specific setup piler is using a postfix
server as smart host which then redirects the messages to exchange online
via a transport rule. EXO accepts the restored messages our postfix sends
but never delivers them to the inbox.
Looking at the message trace in EXO shows that the message is beeing recived
but there are no detailed trace infos available.

Out first guess was also that EXO doesn't like recveiving messages with the
same message ID multiple times. We haven't tried REWRITE_MESSAGE_ID yet but
based on what Alex wrote this seems to not solve the problem.

Von: Karl Rossing <>
Gesendet: Freitag, 16. April 2021 17:54
An: Piler User
Betreff: Re: Restore to O365 fails

We have had the same problem. I meant to open a ticket with Microsoft but so
far have not.

On Fri, Apr 16, 2021 at 8:53 AM Alexander Noack
<<>> wrote:

I do realize that this is very likely not a Piler issue but rather O365
related… but maybe somebody already came across this issue and knows how to
remediate it.

When I restore a deleted email in my O365 account, the message transfer
always fails:

550 4.3.2 QUEUE.TransportAgent; message deleted by transport agent

The Piler server is setup as a connector in Exchange Online. The Smarthost

Mails seem to be originating from

The error states that there is an NDR sent to that address, but even after
assigning that address to myself, no NDR is ever received.

I have set $config['REWRITE_MESSAGE_ID'] = 1;

Any help is greatly appreciated!


Missiles & Space Batteries Limited is registered in Scotland under company
number 162626.  The company's registered office is at Hagmill Road, East
Shawhead, Coatbridge, ML5 4UZ.

Reply via email to