Quantcast

Issues with a Rewriting Gateway

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Issues with a Rewriting Gateway

Dennis Weber

Hi Community,

 

I am currently working on a project for a rewriting gateway with postfix, which shall mask two independent internal domains behind a third external DNS name. In general it should accept mails from @internal1.com and @internal2.com as a Smarthost, rewrite the addresses with a new @newcorp.com domain and send it to the public network. Besides the outgoing rewrite it also needs to rewrite incoming mail to both internal domains and transport them to the right Exchange organizations.

 

I managed to rewrite the outgoing messages with the generic_maps and a simple filetable, but there are still some issues:

 

  • Rewritten incoming messages get a new To field in the header via canonical_maps and they are delivered with the correct transport rule, but the internal mail server receives a mail for @newcorp.com and cannot deliver it to the right mailbox anymore
  • Messages rewritten with header_checks cannot be delivered too, because of the same reason mentioned above
  • Messages from @internal1.com to @internal2.com are rewritten too and not deliverable anymore, because the gateway does not know which transport rule it has to use
  • Encrypted and signed mails are rewritten too and are not useable anymore

 

Therefore I do now have some questions for you:

 

  • Is it possible to do a conditional rewrite with header_checks and mime_header_checks and to filter ancrypted mails and mails from internal1 to internal2 and backwards?
  • Is it possible to totally rewrite incoming mails like those outgoing mails? There are no problems with the generic function, but canonical and header_rewrite just wont work the way I need them.
  • Is it possible at all to create a black box rewrite gateway the way I need it or do I need the internal mail servers to know the external domain in any case?

 

Thank you all a lot in advance for your thoughts and ideas about my problems!

 

With best regards

Dennis Weber

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issues with a Rewriting Gateway

Viktor Dukhovni

> On Apr 23, 2017, at 7:12 AM, Dennis Weber <[hidden email]> wrote:
>  
> I am currently working on a project for a rewriting gateway with postfix, which shall mask two independent internal domains behind a third external DNS name. In general it should accept mails from @internal1.com and @internal2.com as a Smarthost, rewrite the addresses with a new @newcorp.com domain and send it to the public network. Besides the outgoing rewrite it also needs to rewrite incoming mail to both internal domains and transport them to the right Exchange organizations.

See http://www.postfix.org/SOHO_README.html#fantasy

> I managed to rewrite the outgoing messages with the “generic_maps” and a simple filetable

Good, that's the right thing to do outbound, but you should configure the
"smtp_generic_maps" parameter separately for inbound and inbound mail:

        main.cf:
                indexed = ${default_database_type}:${config_directory}/
                relay_generic_maps =
                smtp_generic_maps = ${indexed}generic
                transport_maps = ${indexed}transport
                virtual_alias_maps = ${indexed}virtual
                virtual_alias_domains = example.com

        master.cf:
                ...
                smtp unix ... smtp
                relay unix ... smtp
                        -o smtp_generic_maps=$relay_generic_maps
                ...

        transport:
                # Inbound mail uses the "relay" transport which
                # avoids the outbound "generic" rewrite.
                # Add optional nexthop gateways as appropriate
                internal1.example relay
                internal2.example relay

        virtual:
                # Map external *envelope recipient* addrs to internal
                [hidden email] [hidden email]
                [hidden email] [hidden email]
                ...

        generic:
                # Map internal addrs to external in envelope and headers
                [hidden email] [hidden email]
                [hidden email] [hidden email]
       
> • Messages rewritten with “header_checks” cannot be delivered too, because of the same reason mentioned above

NEVER EVER ATTEMPT OR EVEN THINK ABOUT using header checks for address
rewriting.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Issues with a Rewriting Gateway

Dennis Weber
Hi Viktor,

I have changed my configuration with your recommendation, but the Exchange server behind the gateway is still receiving mails for [hidden email] instead of [hidden email].

Postfix Log:
postfix/smtp[15949]: 08F37AE307: to=<[hidden email]>, orig_to=<[hidden email]>, relay=10.0.0.8[10.0.0.8]:25, delay=0.4, delays=0.04/0.02/0.04/0.3, dsn=2.6.0, status=sent (250 2.6.0 <[hidden email]> [InternalId=someid] Queued mail for delivery)

Exchange Queue:
Last Error: A local loop was detected.
Queue ID: SRV-EXCH01\Submission
Recipients:  [hidden email];2;0;;0;

On the way outgoing everything looks fine, the "From" Field and "Return-To" are rewritten by generic and the mail is delivered fine, only the way incoming won't work.

This is exactly the same behavior I experienced with using canonical_maps und even with the header_checks... :(

Any idea on what I am doing wrong?

With best regards
Dennis Weber


-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Viktor Dukhovni
Gesendet: Sonntag, 23. April 2017 19:19
An: Postfix users <[hidden email]>
Betreff: Re: Issues with a Rewriting Gateway


> On Apr 23, 2017, at 7:12 AM, Dennis Weber <[hidden email]> wrote:
>  
> I am currently working on a project for a rewriting gateway with postfix, which shall mask two independent internal domains behind a third external DNS name. In general it should accept mails from @internal1.com and @internal2.com as a Smarthost, rewrite the addresses with a new @newcorp.com domain and send it to the public network. Besides the outgoing rewrite it also needs to rewrite incoming mail to both internal domains and transport them to the right Exchange organizations.

See https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.postfix.org%2FSOHO_README.html%23fantasy&data=01%7C01%7Cdennis.weber%40atwork-it.com%7Cbf59aaa1f99e418e717d08d48a6cc76b%7Cd827fc609b284520af06b2d51904fa40%7C1&sdata=fm%2Boo4i%2F8gvK1fD6Ka49ciBk3EzeDQthBTISjT2BD4I%3D&reserved=0

> I managed to rewrite the outgoing messages with the “generic_maps” and
> a simple filetable

Good, that's the right thing to do outbound, but you should configure the "smtp_generic_maps" parameter separately for inbound and inbound mail:

        main.cf:
                indexed = ${default_database_type}:${config_directory}/
                relay_generic_maps =
                smtp_generic_maps = ${indexed}generic
                transport_maps = ${indexed}transport
                virtual_alias_maps = ${indexed}virtual
                virtual_alias_domains = example.com

        master.cf:
                ...
                smtp unix ... smtp
                relay unix ... smtp
                        -o smtp_generic_maps=$relay_generic_maps
                ...

        transport:
                # Inbound mail uses the "relay" transport which
                # avoids the outbound "generic" rewrite.
                # Add optional nexthop gateways as appropriate
                internal1.example relay
                internal2.example relay

        virtual:
                # Map external *envelope recipient* addrs to internal
                [hidden email] [hidden email]
                [hidden email] [hidden email]
                ...

        generic:
                # Map internal addrs to external in envelope and headers
                [hidden email] [hidden email]
                [hidden email] [hidden email]
       
> • Messages rewritten with “header_checks” cannot be delivered too,
> because of the same reason mentioned above

NEVER EVER ATTEMPT OR EVEN THINK ABOUT using header checks for address rewriting.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issues with a Rewriting Gateway

Viktor Dukhovni
On Tue, Apr 25, 2017 at 07:26:38AM +0000, Dennis Weber wrote:

> I have changed my configuration with your recommendation, but the Exchange
> server behind the gateway is still receiving mails for [hidden email]
> instead of [hidden email].

Please post your configuration as explained in:

    http://www.postfix.org/DEBUG_README.html#mail

This should also include "postconf -Mf" output with the original
line breaks, do not let Outlook or other mail client reformat the
command output.  Attach as a text file if your mail client is too
difficult to configure to not mangle pasted text.

Also include sample lines from transport, virtual, generic, that
are relevant to the problem at hand.  If you obfuscate addresses,
make sure that each original domain becomes a distinct obfuscated
domain and each original email address localpart becomes a distinct
obfuscated localpart.

> Postfix Log:
> postfix/smtp[15949]: 08F37AE307: to=<[hidden email]>, orig_to=<[hidden email]>, relay=10.0.0.8[10.0.0.8]:25, delay=0.4, delays=0.04/0.02/0.04/0.3, dsn=2.6.0, status=sent (250 2.6.0 <[hidden email]> [InternalId=someid] Queued mail for delivery)

The log entry above shows the opposite of what you say.  The message
came in addressed to (orig_to=) <[hidden email]> and was delivered
to (to=) <[hidden email]>.  Exactly as you asked.  

However, what this does not show is any generic(5) rewriting
performed by the SMTP delivery agent on the fly while delivering
the message.  Perhaps you did not manage to hand the message off
to the right ("relay") transport, or to configure that transport
to not perform the generic(5) rewriting you want for outbound mail.

> Exchange Queue:
> Last Error: A local loop was detected.
> Queue ID: SRV-EXCH01\Submission
> Recipients:  [hidden email];2;0;;0;

> On the way outgoing everything looks fine, the "From" Field and "Return-To"
> are rewritten by generic and the mail is delivered fine, only the way
> incoming won't work.
>
> Any idea on what I am doing wrong?

Either a problem within Exchange, or failure to fully implement
the recipe.  Another possibility is that you've not explained what
you're asking for clearly enough.  Perhaps the envelope recipient
you want to hand to Exchange is not the <[hidden email]>
form.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Issues with a Rewriting Gateway

Dennis Weber
Hi Viktor,

thank you a lot for your time and effort!

I have now activated the verbose option on my smtp and trivial-rewrite and was analyzing the connection log.

Maillog of outgoing mail through the gateway:
http://webertec.net/fileshare/maillog_incoming.txt

Maillog of incoming mail through the gateway:
http://webertec.net/fileshare/maillog_outgoing.txt

The Exchange server at "internal.example" (oldcorp1.com) receives the mail "for" [hidden email], but "To" [hidden email] and therefore it is looping back to the postfix system. The RCPT TO is going to the wrong address.

With best regards
Dennis Weber

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Viktor Dukhovni
Gesendet: Dienstag, 25. April 2017 18:04
An: [hidden email]
Betreff: Re: Issues with a Rewriting Gateway

On Tue, Apr 25, 2017 at 07:26:38AM +0000, Dennis Weber wrote:

> I have changed my configuration with your recommendation, but the
> Exchange server behind the gateway is still receiving mails for
> [hidden email] instead of [hidden email].

Please post your configuration as explained in:

    https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.postfix.org%2FDEBUG_README.html%23mail&data=01%7C01%7Cdennis.weber%40atwork-it.com%7Ce4eb3b84734b45e69dcd08d48bf4a863%7Cd827fc609b284520af06b2d51904fa40%7C1&sdata=rq5NsBt1JyT1H087YZaiqrmFed8VFA4V0XAaL1siYEY%3D&reserved=0

This should also include "postconf -Mf" output with the original line breaks, do not let Outlook or other mail client reformat the command output.  Attach as a text file if your mail client is too difficult to configure to not mangle pasted text.

Also include sample lines from transport, virtual, generic, that are relevant to the problem at hand.  If you obfuscate addresses, make sure that each original domain becomes a distinct obfuscated domain and each original email address localpart becomes a distinct obfuscated localpart.

> Postfix Log:
> postfix/smtp[15949]: 08F37AE307: to=<[hidden email]>,
> orig_to=<[hidden email]>, relay=10.0.0.8[10.0.0.8]:25, delay=0.4,
> delays=0.04/0.02/0.04/0.3, dsn=2.6.0, status=sent (250 2.6.0
> <[hidden email]> [InternalId=someid]
> Queued mail for delivery)

The log entry above shows the opposite of what you say.  The message came in addressed to (orig_to=) <[hidden email]> and was delivered to (to=) <[hidden email]>.  Exactly as you asked.  

However, what this does not show is any generic(5) rewriting performed by the SMTP delivery agent on the fly while delivering the message.  Perhaps you did not manage to hand the message off to the right ("relay") transport, or to configure that transport to not perform the generic(5) rewriting you want for outbound mail.

> Exchange Queue:
> Last Error: A local loop was detected.
> Queue ID: SRV-EXCH01\Submission
> Recipients:  [hidden email];2;0;;0;

> On the way outgoing everything looks fine, the "From" Field and "Return-To"
> are rewritten by generic and the mail is delivered fine, only the way
> incoming won't work.
>
> Any idea on what I am doing wrong?

Either a problem within Exchange, or failure to fully implement the recipe.  Another possibility is that you've not explained what you're asking for clearly enough.  Perhaps the envelope recipient you want to hand to Exchange is not the <[hidden email]> form.

--
        Viktor.

generic_rewrite_outgoing (148 bytes) Download Attachment
postconf_Mf.txt (2K) Download Attachment
postconf_n.txt (2K) Download Attachment
recipient_canonical (148 bytes) Download Attachment
transport_rules (92 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issues with a Rewriting Gateway

Viktor Dukhovni

> On Apr 25, 2017, at 5:31 PM, Dennis Weber <[hidden email]> wrote:
>
> Hi Viktor,
>
> thank you a lot for your time and effort!
>
> I have now activated the verbose option on my smtp and trivial-rewrite and was analyzing the connection log.

You made the incoming stmpd(8) verbose, but all the interesting stuff happens in
the outgoing smtp(8), for which the logs have only:

    Apr 25 23:00:19 srv-rewr01 postfix/smtp[20290]:
        Untrusted TLS connection established to 10.0.0.8[10.0.0.8]:25:
        TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
    Apr 25 23:00:19 srv-rewr01 postfix/smtp[20290]: 34DE4AE307:
        to=<[hidden email]>, orig_to=<[hidden email]>,
        relay=10.0.0.8[10.0.0.8]:25, delay=0.52, delays=0.08/0/0.04/0.4,
        dsn=2.6.0, status=sent (250 2.6.0
        <[hidden email]>
        [InternalId=2486786064455] Queued mail for delivery)

The rewriting upstream of smtp(8) happened exactly as I understood
you to have said you wanted upthread.

> The Exchange server at "internal.example" (oldcorp1.com) receives the mail "for" [hidden email],
> but "To" [hidden email] and therefore it is looping back to the postfix system.
> The RCPT TO is going to the wrong address.

That is *not* how Exchange works.  It does not care at all about the content
of the message headers.  The delivery is based entirely on the message
envelope recipient address.  In this case <[hidden email]>.
That address is matched (after prepending "smtp:") against the LDAP
proxyAddresses attribute in Active Directory.

What proxyAddresses in Exchange are associated with "test.testersen"?
Report the "mail", "SAMAccountName" and "proxyAddresses" attributes of
the relevant user object.

> <generic_rewrite_outgoing><postconf_Mf.txt><postconf_n.txt><recipient_canonical><transport_rules>

These looked mostly ok.  You should not use or need "recipient_canonical"
mappings.  You did not post the relevant entries from the virtual_alias table.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Issues with a Rewriting Gateway

Dennis Weber
> On Apr 25, 2017, at 11:52 PM, Viktor Dukhovni wrote:
>
> You made the incoming stmpd(8) verbose, but all the interesting stuff happens in the outgoing smtp(8), for which the logs have only:
>
>     Apr 25 23:00:19 srv-rewr01 postfix/smtp[20290]:
> Untrusted TLS connection established to 10.0.0.8[10.0.0.8]:25:
> TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>    Apr 25 23:00:19 srv-rewr01 postfix/smtp[20290]: 34DE4AE307:
> to=<[hidden email]>, orig_to=<[hidden email]>,
> relay=10.0.0.8[10.0.0.8]:25, delay=0.52, delays=0.08/0/0.04/0.4,
> dsn=2.6.0, status=sent (250 2.6.0
> <[hidden email]>
> [InternalId=2486786064455] Queued mail for delivery)
>
> The rewriting upstream of smtp(8) happened exactly as I understood you to have said you wanted upthread.
>
> That is *not* how Exchange works.  It does not care at all about the content of the message headers.
> The delivery is based entirely on the message envelope recipient address.  In this case <[hidden email]>.
> That address is matched (after prepending "smtp:") against the LDAP proxyAddresses attribute in Active Directory.
>
> What proxyAddresses in Exchange are associated with "test.testersen"?
> Report the "mail", "SAMAccountName" and "proxyAddresses" attributes of the relevant user object.

The samAccountName of this user is "ttestersen" and he does only have "[hidden email]" associated as proxyaddress/reply-to. I thought if I use "recipient_canonical_maps" and tell it with "recipient_canonical_classes" it should change the "envelope_recipient" AND "envelope_header", the postfix would RCPT TO the message to the new address and not the old one. From my perspective it is only rewriting the header and not the envelope, or do I get something in the message processing completely wrong?

>> <generic_rewrite_outgoing><postconf_Mf.txt><postconf_n.txt><recipient_canonical><transport_rules>
>
>These looked mostly ok.  You should not use or need "recipient_canonical"
>mappings.  You did not post the relevant entries from the virtual_alias table.

In my last tests I used the "virtual" table only for unqualified addresses like root and postmaster on my GW machine. I have now added those lines to it:

postmaster      [hidden email]
abuse           [hidden email]
double-bounce   [hidden email]
root            [hidden email]
[hidden email] [hidden email]
[hidden email] [hidden email]

Same result, the mail does not get a new address in the envelope, just the header "To" is rewritten and the mail is looped back to the GW by my Exchange server.

Logfile with additional activated verbose output on "smtp" and "relay":
http://webertec.net/fileshare/maillog_26042017_1126.txt

Do I get this log the right way, that I rewrite the incoming "To" field and write it back with "generic" when the mail is relayed to my internal servers? Or can you see another source for my errors?

With best regards
Dennis Weber
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issues with a Rewriting Gateway

Viktor Dukhovni

> On Apr 26, 2017, at 5:36 AM, Dennis Weber <[hidden email]> wrote:
>
>> On Apr 25, 2017, at 11:52 PM, Viktor Dukhovni wrote:
>>
>> You made the incoming stmpd(8) verbose, but all the interesting stuff happens in the outgoing smtp(8), for which the logs have only:
>>
>>    Apr 25 23:00:19 srv-rewr01 postfix/smtp[20290]:
>> Untrusted TLS connection established to 10.0.0.8[10.0.0.8]:25:
>> TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>>   Apr 25 23:00:19 srv-rewr01 postfix/smtp[20290]: 34DE4AE307:
>> to=<[hidden email]>, orig_to=<[hidden email]>,
>> relay=10.0.0.8[10.0.0.8]:25, delay=0.52, delays=0.08/0/0.04/0.4,
>> dsn=2.6.0, status=sent (250 2.6.0
>> <[hidden email]>
>> [InternalId=2486786064455] Queued mail for delivery)
>>
>> The rewriting upstream of smtp(8) happened exactly as I understood you to have said you wanted upthread.

I repeat, the recipient envelope address in the message queue file is the
one logged in the "to=<...>" part of the delivery log entry.  This appears
to be the address you want.  Provided you've run "postfix reload" after
making changes to master.cf, your "relay" delivery agent (presumably
configured in the "transport" table for "oldcorp1.com") will leave that
address unchanged, as a result of the "smtp_generic_maps" override in
master.cf.

[ Mystery solved at the bottom of this post ]

>> That is *not* how Exchange works.  It does not care at all about the content of the message headers.
>> The delivery is based entirely on the message envelope recipient address.  In this case <[hidden email]>.
>> That address is matched (after prepending "smtp:") against the LDAP proxyAddresses attribute in Active Directory.
>>
>> What proxyAddresses in Exchange are associated with "test.testersen"?
>> Report the "mail", "SAMAccountName" and "proxyAddresses" attributes of the relevant user object.
>
> The samAccountName of this user is "ttestersen" and he does only have "[hidden email]" associated as proxyaddress/reply-to.

No idea what you mean by "reply-to" here, but that should not be relevant.  Where does exchange
sende this user's email?  To a mailbox?  Or forwards it somewhere?

> I thought if I use "recipient_canonical_maps" and tell it with "recipient_canonical_classes" it should change the "envelope_recipient" AND "envelope_header", the postfix would RCPT TO the message to the new address and not the old one.

The correct mechanism for envelope recipient rewriting is virtual_alias_maps,
not recipient_canonical_maps.  Avoid the latter.

> <generic_rewrite_outgoing><postconf_Mf.txt><postconf_n.txt><recipient_canonical><transport_rules>
>>
>> These looked mostly ok.  You should not use or need "recipient_canonical"
>> mappings.  You did not post the relevant entries from the virtual_alias table.
>
> In my last tests I used the "virtual" table only for unqualified addresses like root and postmaster on my GW machine. I have now added those lines to it:
>
> postmaster      [hidden email]
> abuse           [hidden email]
> double-bounce   [hidden email]
> root            [hidden email]
> [hidden email] [hidden email]
> [hidden email] [hidden email]

Good.  Provided that "oldcorp1.com" and "oldcorp2.com" (via the transport table,
did you remember to "postmap" the updated "transport", and other tables?) are
resolved to the "relay" transport you should be set.

> Same result, the mail does not get a new address in the envelope,
> Logfile with additional activated verbose output on "smtp" and "relay":
> http://webertec.net/fileshare/maillog_26042017_1126.txt

This delivery shows:

   Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: dict_open: hash:/etc/postfix/generic_rewrite_outgoing

which means that it is not using the "relay" master.cf entry with the
smtp_generic_maps override:

    relay unix - - n - - smtp
       -o smtp_generic_maps=$relay_generic_maps

(set empty in main.cf).  Perhaps you neglected to "postmap" the
updated "transport" and other tables.

It also has:

Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: nexthop
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: [10.0.0.8]:25
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: sender
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: [hidden email]
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: recipient_count
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: 1
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: smtp socket: wanted attribute: original_recipient
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: original_recipient
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: [hidden email]
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: recipient
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: [hidden email]
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: dsn_orig_rcpt
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: rfc822;[hidden email]

Showing a request to deliver to <[hidden email]> from an original
value of <[hidden email]>, all as you ask for so far...

We then see smtp_generic_maps undoing the desired rewrite:

Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: maps_find: smtp_generic_maps: hash:/etc/postfix/generic_rewrite_outgoing(0,lock|fold_fix): [hidden email] = [hidden email]
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: mail_addr_find: [hidden email] -> [hidden email]

So perhaps you're using the wrong transport, or the master.cf override is
not implemented correctly.  Most likely failure to "postmap" the transport
table.

Which leads to:

Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: > 10.0.0.8[10.0.0.8]:25: RCPT TO:<[hidden email]> ORCPT=rfc822;[hidden email]
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: > 10.0.0.8[10.0.0.8]:25: DATA

So you're close, but not yet sending the domains in question to the "relay"
transport as required.  Indeed the same verbose logs show:

Apr 26 11:24:14 srv-rewr01 postfix/trivial-rewrite[21661]: `[hidden email]' -> `[hidden email]' -> (`smtp' `[10.0.0.8]:25' `[hidden email]' `2048')

That's "smtp" not "relay".  Upthread you posted your transport file, and I
failed to notice:

   oldcorp1.com smtp:[10.0.0.8]:25
   oldcorp2.com smtp:[10.0.0.9]:25

while my upthread recipe was:

        transport:
                # Inbound mail uses the "relay" transport which
                # avoids the outbound "generic" rewrite.
                # Add optional nexthop gateways as appropriate
                internal1.example relay
                internal2.example relay

So change your transport table to:

   oldcorp1.com relay:[10.0.0.8]:25
   oldcorp2.com relay:[10.0.0.9]:25

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Issues with a Rewriting Gateway

Dennis Weber
Hi Viktor,

You saved me, the rewrite is finally working as expected! :)

I thought the "smtp" in the transport map is linked to the protocol used and not the transport agent from my master.cf file. Everything is working fine now, thanks a lot again!

Now there is only one thing left: When I send an appointment from an Exchange server, relayed over the Postfix gateway, there are no generic rules for rewriting applied. Do you have a last hint for me, in which direction I should focus my research on, why appointments are not rewritten?

With best regards,
Dennis Weber

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Viktor Dukhovni
Gesendet: Mittwoch, 26. April 2017 16:17
An: Postfix users <[hidden email]>
Betreff: Re: Issues with a Rewriting Gateway


> On Apr 26, 2017, at 5:36 AM, Dennis Weber <[hidden email]> wrote:
>
>> On Apr 25, 2017, at 11:52 PM, Viktor Dukhovni wrote:
>>
>> You made the incoming stmpd(8) verbose, but all the interesting stuff happens in the outgoing smtp(8), for which the logs have only:
>>
>>    Apr 25 23:00:19 srv-rewr01 postfix/smtp[20290]:
>> Untrusted TLS connection established to 10.0.0.8[10.0.0.8]:25:
>> TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>>   Apr 25 23:00:19 srv-rewr01 postfix/smtp[20290]: 34DE4AE307:
>> to=<[hidden email]>, orig_to=<[hidden email]>,
>> relay=10.0.0.8[10.0.0.8]:25, delay=0.52, delays=0.08/0/0.04/0.4,
>> dsn=2.6.0, status=sent (250 2.6.0
>> <[hidden email]>
>> [InternalId=2486786064455] Queued mail for delivery)
>>
>> The rewriting upstream of smtp(8) happened exactly as I understood you to have said you wanted upthread.

I repeat, the recipient envelope address in the message queue file is the one logged in the "to=<...>" part of the delivery log entry.  This appears to be the address you want.  Provided you've run "postfix reload" after making changes to master.cf, your "relay" delivery agent (presumably configured in the "transport" table for "oldcorp1.com") will leave that address unchanged, as a result of the "smtp_generic_maps" override in master.cf.

[ Mystery solved at the bottom of this post ]

>> That is *not* how Exchange works.  It does not care at all about the content of the message headers.
>> The delivery is based entirely on the message envelope recipient address.  In this case <[hidden email]>.
>> That address is matched (after prepending "smtp:") against the LDAP proxyAddresses attribute in Active Directory.
>>
>> What proxyAddresses in Exchange are associated with "test.testersen"?
>> Report the "mail", "SAMAccountName" and "proxyAddresses" attributes of the relevant user object.
>
> The samAccountName of this user is "ttestersen" and he does only have "[hidden email]" associated as proxyaddress/reply-to.

No idea what you mean by "reply-to" here, but that should not be relevant.  Where does exchange sende this user's email?  To a mailbox?  Or forwards it somewhere?

> I thought if I use "recipient_canonical_maps" and tell it with "recipient_canonical_classes" it should change the "envelope_recipient" AND "envelope_header", the postfix would RCPT TO the message to the new address and not the old one.

The correct mechanism for envelope recipient rewriting is virtual_alias_maps, not recipient_canonical_maps.  Avoid the latter.

> <generic_rewrite_outgoing><postconf_Mf.txt><postconf_n.txt><recipient_
> canonical><transport_rules>
>>
>> These looked mostly ok.  You should not use or need "recipient_canonical"
>> mappings.  You did not post the relevant entries from the virtual_alias table.
>
> In my last tests I used the "virtual" table only for unqualified addresses like root and postmaster on my GW machine. I have now added those lines to it:
>
> postmaster      [hidden email]
> abuse           [hidden email]
> double-bounce   [hidden email]
> root            [hidden email]
> [hidden email] [hidden email]
> [hidden email] [hidden email]

Good.  Provided that "oldcorp1.com" and "oldcorp2.com" (via the transport table, did you remember to "postmap" the updated "transport", and other tables?) are resolved to the "relay" transport you should be set.

> Same result, the mail does not get a new address in the envelope,
> Logfile with additional activated verbose output on "smtp" and "relay":
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebe
> rtec.net%2Ffileshare%2Fmaillog_26042017_1126.txt&data=01%7C01%7Cdennis
> .weber%40atwork-it.com%7C640a81aa6b434153091d08d48caee416%7Cd827fc609b
> 284520af06b2d51904fa40%7C1&sdata=tw4om5uumLiwRaJVMsxA%2FLWcLDdsMceBogI
> nhMz8t6o%3D&reserved=0

This delivery shows:

   Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: dict_open: hash:/etc/postfix/generic_rewrite_outgoing

which means that it is not using the "relay" master.cf entry with the smtp_generic_maps override:

    relay unix - - n - - smtp
       -o smtp_generic_maps=$relay_generic_maps

(set empty in main.cf).  Perhaps you neglected to "postmap" the updated "transport" and other tables.

It also has:

Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: nexthop Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: [10.0.0.8]:25 Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: sender Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: [hidden email] Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: recipient_count Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: 1 Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: smtp socket: wanted attribute: original_recipient Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: original_recipient Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: [hidden email] Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: recipient Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: [hidden email] Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute name: dsn_orig_rcpt Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: input attribute value: rfc822;[hidden email]

Showing a request to deliver to <[hidden email]> from an original value of <[hidden email]>, all as you ask for so far...

We then see smtp_generic_maps undoing the desired rewrite:

Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: maps_find: smtp_generic_maps: hash:/etc/postfix/generic_rewrite_outgoing(0,lock|fold_fix): [hidden email] = [hidden email] Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: mail_addr_find: [hidden email] -> [hidden email]

So perhaps you're using the wrong transport, or the master.cf override is not implemented correctly.  Most likely failure to "postmap" the transport table.

Which leads to:

Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: > 10.0.0.8[10.0.0.8]:25: RCPT TO:<[hidden email]> ORCPT=rfc822;[hidden email]
Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: > 10.0.0.8[10.0.0.8]:25: DATA

So you're close, but not yet sending the domains in question to the "relay"
transport as required.  Indeed the same verbose logs show:

Apr 26 11:24:14 srv-rewr01 postfix/trivial-rewrite[21661]: `[hidden email]' -> `[hidden email]' -> (`smtp' `[10.0.0.8]:25' `[hidden email]' `2048')

That's "smtp" not "relay".  Upthread you posted your transport file, and I failed to notice:

   oldcorp1.com smtp:[10.0.0.8]:25
   oldcorp2.com smtp:[10.0.0.9]:25

while my upthread recipe was:

        transport:
                # Inbound mail uses the "relay" transport which
                # avoids the outbound "generic" rewrite.
                # Add optional nexthop gateways as appropriate
                internal1.example relay
                internal2.example relay

So change your transport table to:

   oldcorp1.com relay:[10.0.0.8]:25
   oldcorp2.com relay:[10.0.0.9]:25

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issues with a Rewriting Gateway

Viktor Dukhovni

> On May 10, 2017, at 6:34 AM, Dennis Weber <[hidden email]> wrote:
>
> Now there is only one thing left: When I send an appointment from an Exchange
> server, relayed over the Postfix gateway, there are no generic rules for
> rewriting applied. Do you have a last hint for me, in which direction I should
> focus my research on, why appointments are not rewritten?

The email message containing the iCal object *is* rewritten, just any other
email message.  However, what the (Outlook or some other iCal client) sees
is the enclosed invite, not the email message.

Your best bet is to make sure that the primary email address (Active
Directory "mail" address of each user) is in fact their primary public
address, and requires no rewriting.

Rewriting calendar invites is not a job for Postfix, and while in
principle possible with the right content filters or milters, is
not a design I would recommend.

--
        Viktor.

Loading...