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: [email protected] [mailto:[email protected]] Im Auftrag von Viktor Dukhovni Gesendet: Mittwoch, 26. April 2017 16:17 An: Postfix users <[email protected]> Betreff: Re: Issues with a Rewriting Gateway > On Apr 26, 2017, at 5:36 AM, Dennis Weber <[email protected]> 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=<[email protected]>, orig_to=<[email protected]>, >> 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 >> >> <am5pr0402mb278530d3d61fc0e224ad6466c3...@am5pr0402mb2785.eurprd04.prod.outlook.com> >> [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 <[email protected]>. >> 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 > "[email protected]" 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 [email protected] > abuse [email protected] > double-bounce [email protected] > root [email protected] > [email protected] [email protected] > [email protected] [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 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;[email protected] Showing a request to deliver to <[email protected]> from an original value of <[email protected]>, 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): [email protected] = [email protected] Apr 26 11:24:14 srv-rewr01 postfix/smtp[21663]: mail_addr_find: [email protected] -> [email protected] 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:<[email protected]> ORCPT=rfc822;[email protected] 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]: `[email protected]' -> `[email protected]' -> (`smtp' `[10.0.0.8]:25' `[email protected]' `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.
