Recipient domain substitution

[John Schmerold]

I want messages sent to [hidden email] to be redirected to
[hidden email]

Until this morning, adding canonical_maps = hash:/etc/postfix/canonical
to main.cf got the job done.

canonical contained:
   @tld1.com @redirected.com

Now the remote server is rejecting the message with this error:
     <[hidden email]> (expanded from <[hidden email]>): host
         mx10.redirected.com[104.119.187.151] said: 550 Unauthorized
recipient: domain part

How do I persuade Postfix to replace tld1.com with redirected.com,
without the "expanded from" issue (I am not even sure what expanded from
means)?

--
John Schmerold
Katy Computer Systems, Inc
https://katycomputer.com
St Louis

[Wietse Venema]

John Schmerold:

> I want messages sent to [hidden email] to be redirected to
> [hidden email]
>
> Until this morning, adding canonical_maps = hash:/etc/postfix/canonical
> to main.cf got the job done.
>
> canonical contained:
>    @tld1.com @redirected.com
>
> Now the remote server is rejecting the message with this error:
>      <[hidden email]> (expanded from <[hidden email]>): host
>          mx10.redirected.com[104.119.187.151] said: 550 Unauthorized
> recipient: domain part

Postix sends "RCPT TO:<[hidden email]>" to the remote SMTP
server (not the 'expanded from' stuff, that would not make any
sense).

Postfix adds "(expanded from <[hidden email]>)" only in the
NON-DELIVERY NOTIFICATION, so that you can see why it sends
mail to [hidden email].

> How do I persuade Postfix to replace tld1.com with redirected.com,
> without the "expanded from" issue (I am not even sure what expanded from
> means)?

It already does that.

        Wietse

[John Schmerold]

On 12/22/2020 2:31 PM, Wietse Venema wrote:

> John Schmerold:
>> I want messages sent to [hidden email] to be redirected to
>> [hidden email]
>>
>> Until this morning, adding canonical_maps = hash:/etc/postfix/canonical
>> to main.cf got the job done.
>>
>> canonical contained:
>>     @tld1.com @redirected.com
>>
>> Now the remote server is rejecting the message with this error:
>>       <[hidden email]> (expanded from <[hidden email]>): host
>>           mx10.redirected.com[104.119.187.151] said: 550 Unauthorized
>> recipient: domain part
> Postix sends "RCPT TO:<[hidden email]>" to the remote SMTP
> server (not the 'expanded from' stuff, that would not make any
> sense).
>
> Postfix adds "(expanded from <[hidden email]>)" only in the
> NON-DELIVERY NOTIFICATION, so that you can see why it sends
> mail to [hidden email].
>
>> How do I persuade Postfix to replace tld1.com with redirected.com,
>> without the "expanded from" issue (I am not even sure what expanded from
>> means)?
> It already does that.
>
> Wietse

I should have looked at the log before sending this note. Postfix is
including a " orig_to=" header when sending to the destination server,
that is causing our problem.

Is there a way to turn off "orig_to=" in this situation?

[Viktor Dukhovni]

On Tue, Dec 22, 2020 at 02:57:13PM -0600, John Schmerold wrote:

> I should have looked at the log before sending this note. Postfix is
> including a " orig_to=" header when sending to the destination server,
> that is causing our problem.

There is no such thing as an "orig_to=" header.

> Is there a way to turn off "orig_to=" in this situation?

That's the wrong question.  If the remote server is unhappy with DSN
"ORCPT", you can ignore that ESMTP feature advertisement, but before
wasting your time with that, it would sure help to actually understand
what's wrong, rather than make random guesses.

- Capture and analyse traffic between Postfix and the remote server,
  to understand how to reproduce the problem outside Postfix.

- Open a manual SMTP session to the remote server, reproduce the
  problem, and then report your findings here.  Depending on what
  you've found, we can suggest viable alternatives.

- If the solution is obvious, try tweaking the manual SMTP interaction
  to achieve the desired result, then see whether you can persuade
  Postfix to send in a manner that the remote server will not object
  to.

--
    Viktor.

[John Schmerold]

On 12/22/2020 3:10 PM, Viktor Dukhovni wrote:

> On Tue, Dec 22, 2020 at 02:57:13PM -0600, John Schmerold wrote:
>
>> I should have looked at the log before sending this note. Postfix is
>> including a " orig_to=" header when sending to the destination server,
>> that is causing our problem.
> There is no such thing as an "orig_to=" header.
>
>> Is there a way to turn off "orig_to=" in this situation?
> That's the wrong question.  If the remote server is unhappy with DSN
> "ORCPT", you can ignore that ESMTP feature advertisement, but before
> wasting your time with that, it would sure help to actually understand
> what's wrong, rather than make random guesses.
>
> - Capture and analyse traffic between Postfix and the remote server,
>    to understand how to reproduce the problem outside Postfix.
>
> - Open a manual SMTP session to the remote server, reproduce the
>    problem, and then report your findings here.  Depending on what
>    you've found, we can suggest viable alternatives.
>
> - If the solution is obvious, try tweaking the manual SMTP interaction
>    to achieve the desired result, then see whether you can persuade
>    Postfix to send in a manner that the remote server will not object
>    to.

You nailed it - we need to disable ORCPT, I was hoping
"enable_original_recipient=no" would get the job done.

What is the correct directive?

[Wietse Venema]

John Schmerold:

> On 12/22/2020 3:10 PM, Viktor Dukhovni wrote:
> > On Tue, Dec 22, 2020 at 02:57:13PM -0600, John Schmerold wrote:
> >
> >> I should have looked at the log before sending this note. Postfix is
> >> including a " orig_to=" header when sending to the destination server,
> >> that is causing our problem.
> > There is no such thing as an "orig_to=" header.
> >
> >> Is there a way to turn off "orig_to=" in this situation?
> > That's the wrong question.  If the remote server is unhappy with DSN
> > "ORCPT", you can ignore that ESMTP feature advertisement, but before
> > wasting your time with that, it would sure help to actually understand
> > what's wrong, rather than make random guesses.
> >
> > - Capture and analyse traffic between Postfix and the remote server,
> >    to understand how to reproduce the problem outside Postfix.
> >
> > - Open a manual SMTP session to the remote server, reproduce the
> >    problem, and then report your findings here.  Depending on what
> >    you've found, we can suggest viable alternatives.
> >
> > - If the solution is obvious, try tweaking the manual SMTP interaction
> >    to achieve the desired result, then see whether you can persuade
> >    Postfix to send in a manner that the remote server will not object
> >    to.
>
> You nailed it - we need to disable ORCPT, I was hoping
> "enable_original_recipient=no" would get the job done.
>
> What is the correct directive?

To disable DSN support for example.com:

http://www.postfix.org/postconf.5.html#smtp_discard_ehlo_keyword_address_maps 
(use a PCRE table to limit this to the server's network range)

http://www.postfix.org/postconf.5.html#smtp_discard_ehlo_keywords 
(disables DSN support for all outbound mail)

        Wietse