3

I am having a mail delivered to a Postfix mail server.

  • That mail got the following address: else%[email protected] (It is basically a url encoded version of [email protected], 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 <else%[email protected]>: Relay access denied; from=<[email protected]> to=<else%[email protected]> 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:

  • Disable/Enable allow_percent_hack to see if that is the reason, I get rejected. Nothing changes for either setting.
  • Tried to change the recipient_delimiter to '%', 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. :)

Edit #1:

I found a difference in the flags for a working and a non-working message.

  • Delivered message: Flag: 1024
  • Not Delivered message: Flag: 1026

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 @, !, or % 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

or

b) Hack a little something together to actually route him "back" to my server.

Improve this question
4
  • Is this happening when you send mail locally or only from a specific source? Email clients should be sending + as a literal plus and not URL encoded.
    – scuba_mike
    Commented Jan 2, 2020 at 18:26
  • Yes, they should. But for this question it does not matter where the email is coming from, because we are not investigating the source here. I am searching for a solution on how the destination accepts the email. :)
    – func0der
    Commented Jan 3, 2020 at 19:40
  • Since the % in email addresses was abused for spam delivery at large scale in the past, most mail delivery services today simply don't allows its usage at all. It seems that Outlook.com is one of those services, so either you need to rewrite the address or stop using the % character.
    – Marc Stürmer
    Commented Jan 3, 2020 at 21:48
  • 2
    Maybe a typo in your question, but else%[email protected] is not a URL encoded version of [email protected] as you are missing the B in %2B (URL encoded +). In else%[email protected], the % is a literal % in the local-part (which is strictly valid as far as the RFCs go).
    – MrWhite
    Commented Jan 8, 2020 at 23:00

1 Answer 1

Reset to default
5
+50

The combination of these two settings does the trick:

allow_percent_hack = no
allow_untrusted_routing = yes

But be careful! The Postfix documentation warns about the potential for "a nasty open relay loophole" when overriding the default setting of allow_untrusted_routing.

Without these settings, Postfix rejects this kind of destination address because the default setting allow_percent_hack = yes tells Postfix to support the obsolete source routing mechanism known as "the so-called %-hack", as described in Section 7 of RFC 1711, while the default setting allow_untrusted_routing = no tells Postfix to reject source routing from untrusted clients.

In other words, Postfix rejects this kind of destination by default because it thinks else%[email protected] means "deliver to else@2bsomething by way of domain.com", but only trusted clients are allowed to do that, due to spammers.

Improve this answer
1
  • 1
    Works like a charm :). The indepth documentation is great. I did not came across these infos, even though I spent hours reading their doc.
    – func0der
    Commented Jan 9, 2020 at 15:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .