I am having a mail delivered to a Postfix mail server.
- That mail got the following address:
email@example.com(It is basically a url encoded version of
firstname.lastname@example.org, which should be valid by RFC.)
- The sender's mail server is being told to go way with this message:
NOQUEUE: reject: RCPT from randostring.outbound.protection.outlook.com[...]: 454 4.7.1 <email@example.com>: Relay access denied; from=<firstname.lastname@example.org> to=<email@example.com> proto=ESMTP helo=<morerando.outbound.protection.outlook.com>
- The log tells me:
generic_checks: name=defer_unauth_destination status=2, which I assume is the problem here.
- I have a MySQL lookup for the
$virtual_alias_domains, which does not get queried during the time the log message above is created. I think it might be cached for some time, but I could be totally wrong here.
What I have tried:
allow_percent_hackto see if that is the reason, I get rejected. Nothing changes for either setting.
- Tried to change the
recipient_delimiterto '%', which did not change anything.
My question: How can I force postfix to deliver this email? I really do not need a permanent solutions, as I consider this to be an edge case.
Bonus points, if you can explain to me, why this email is not received in the first place, because I really want to know why this is happening. :)
I found a difference in the flags for a working and a non-working message.
- Delivered message:
- Not Delivered message:
By looking at different places in the source code (Flag definition: https://github.com/vdukhovni/postfix/blob/bfff4380a3b6fac2513c73531ee3a79212c08660/postfix/src/global/resolve_clnt.h#L36-L37 and Flag usage: https://github.com/vdukhovni/postfix/blob/ed3f86da7c3e15cf1ec57241c1f6036d82b790da/postfix/src/trivial-rewrite/resolve.c#L467-L468), I found out, that as soon as there is another
% in the email address, it sets a
routed flag, which is then handled later on.
What I have not found out yet is, how can I
a) prevent that from happening
b) Hack a little something together to actually route him "back" to my server.
+as a literal plus and not URL encoded.
firstname.lastname@example.org not a URL encoded version of
email@example.com you are missing the
%is a literal
%in the local-part (which is strictly valid as far as the RFCs go).