randmap getting precedence in transport_maps?
Hi everyone,
I'm trying to implement load balancing thanks to /transport_maps/ and
/randmap/ as described in postfix 3.0 release notes[1].
/etc/postfix/local_transport_map
my.domain :
.my.domain :
(where myhostname = myorigin = virtual_mailbox_domains = my.domain)
Then I have in main.cf: transport_maps =
hash:/etc/postfix/local_transport_map randmap:{smtp:[relay1.com]:587
smtp:[relay2.com]:587}
(with /etc/postfix/local_transport_map being postmap'ed, and postfix
reloaded)
*What I expected*: incoming mail for my.domain to be delivered locally
(virtual), outgoing mail to be balance-relayed through relay1 and relay2.
*What I get*: incoming and outgoing mail are being balance-relayed
through relay1 and relay2.
*Questions*:
* How do I make sure that incoming mail for locally-managed domains is
delivered locally, not relayed?
* Could it have something to do with local delivery being 'virtual'
and not 'local'?
Thank you very much in advance,
Nico
P.S.: I'm running postfix 3.5.6. Also, I believe this question[2] is
showing the same issue.
[1]
http://postfix.cs.utah.edu/source/official/postfix-3.0.0-RC1.RELEASE_NOTES
[2]
https://stackoverflow.com/questions/62561912/how-to-configure-postfix-with-transport-maps-and-randmap
OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: randmap getting precedence in transport_maps?
Nicolas JEAN: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. > Hi everyone, > > I'm trying to implement load balancing thanks to /transport_maps/ and > /randmap/ as described in postfix 3.0 release notes[1]. > > /etc/postfix/local_transport_map > > my.domain ?? : > .my.domain ? : > > (where myhostname = myorigin = virtual_mailbox_domains = my.domain) Did notice any warnings from Postfix with "do not list domain XXX in both YYY and ZZZ"? > *Questions*: > > * How do I make sure that incoming mail for locally-managed domains is > delivered locally, not relayed? With ":" lookup results in a transport map before the randmap. The transport map must return ":" for the recipient domain AFTER canonical and virtual alias mapping. As documented, canonical and virtual alias mapping happen before transport map lookup. Have you verified that the recipient domain after canonical and virtual alias mapping matches the transport map? Does the lookup return ":"? Postfix logs the recipient domain as "to-". Wietse
Re: randmap getting precedence in transport_maps?
Hi Wietse, Thanks for your quick answer! Wietse Venema: /etc/postfix/local_transport_map my.domain ?? : .my.domain ? : (where myhostname = myorigin = virtual_mailbox_domains = my.domain) Did notice any warnings from Postfix with "do not list domain XXX in both YYY and ZZZ"? Not with this configuration. Some time ago I did, but the "do not list" warning message was about not including /mydestination/ in /virtual_mailbox_domains/ if I remember correctly-- very useful by the way. * How do I make sure that incoming mail for locally-managed domains is delivered locally, not relayed? With ":" lookup results in a transport map before the randmap. The transport map must return ":" for the recipient domain AFTER canonical and virtual alias mapping. As documented, canonical and virtual alias mapping happen before transport map lookup. Have you verified that the recipient domain after canonical and virtual alias mapping matches the transport map? Does the lookup return ":"? Postfix logs the recipient domain as "to-". In this case there should be no canonical or virtual alias for the recipient email address. It's a plain mailbox defined in the virtual_mailbox_maps file as "contact@my.domain my.domain/contact/". Here is the complete log output of the smtp session: Feb 24 15:18:37 my.domain postfix/smtpd[4622]: B08949E76C: client=unknown[7.7.7.7] Feb 24 15:18:37 my.domain postfix/cleanup[4627]: B08949E76C: message-id=<9bc3be89-b254-08b4-c00f-3afc30101...@external.com> Feb 24 15:18:37 my.domain postfix/qmgr[4621]: B08949E76C: from=, size=2764, nrcpt=1 (queue active) Feb 24 15:18:37 my.domain postfix/smtpd[4622]: disconnect from unknown[7.7.7.7] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Feb 24 15:18:38 my.domain postfix/smtp[4628]: Untrusted TLS connection established to relay2.com[2.2.2.2]:587: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Feb 24 15:18:38 my.domain postfix/smtp[4628]: B08949E76C: to=, relay=relay2.com[2.2.2.2]:587, delay=0.76, delays=0.04/0.01/0.38/0.33, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 29A7484FC6) Feb 24 15:18:38 my.domain postfix/qmgr[4621]: B08949E76C: removed If I'm correct, the contact@my.domain wasn't modified by any alias (as shown by 'to=<'). But this final email address still doesn't match against the "my.domain :" entry in /etc/postfix/local_transport_map, for some reason. And so the email gets relayed to relay2.com from the randmap. I'm running short of ideas as to what I'm doing wrong, so any idea is welcome. Nico OpenPGP_0x23459069119D37B6.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: randmap getting precedence in transport_maps?
Nicolas JEAN: > Feb 24 15:18:38 my.domain postfix/smtp[4628]: B08949E76C: > to=, relay=relay2.com[2.2.2.2]:587, delay=0.76, > delays=0.04/0.01/0.38/0.33, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued > as 29A7484FC6) > > If I'm correct, the contact@my.domain wasn't modified by any alias (as > shown by 'to=<'). But this final email address still doesn't match > against the "my.domain :" entry in /etc/postfix/local_transport_map, for > some reason. Well there is your problem. > And so the email gets relayed to relay2.com from the randmap. > > I'm running short of ideas as to what I'm doing wrong, so any idea is > welcome. Instead of arguing what should be in the file, look at what is actually in there. postmap -s /etc/postfix/local_transport_map If the above is not conclusive, look for "invisible" text with: postmap -s /etc/postfix/local_transport_map | od -cb Wietse
persistent log of sent emails?
I know that postfix writes to a log: However there is a lot of diagnostics in the standard log that I am not interested to keep for a longer period of time. Is there a way to tell postfix to write a distinct log of delivered emails (delivered = next hop, not necessarily destination)? Thanks, Joachim
Re: randmap getting precedence in transport_maps?
Em 24/02/2022 14:03, Wietse Venema escreveu:
Nicolas JEAN:
Feb 24 15:18:38 my.domain postfix/smtp[4628]: B08949E76C:
to=, relay=relay2.com[2.2.2.2]:587, delay=0.76,
delays=0.04/0.01/0.38/0.33, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
as 29A7484FC6)
If I'm correct, thecontact@my.domain wasn't modified by any alias (as
shown by 'to=<'). But this final email address still doesn't match
against the "my.domain :" entry in /etc/postfix/local_transport_map, for
some reason.
Well there is your problem.
Instead of arguing what should be in the file, look at what is
actually in there.
postmap -s /etc/postfix/local_transport_map
The database file seems correct also when looking with postmap -s.
I ran some more tests.
### Tests without randmap ###
transport_maps = hash:/etc/postfix/local_transport_map
Having "my.domain :" or "my.domain lmtp:unix:private/dovecot-lmtp"
doesn't modify default behaviour (set by virtual_transport =
lmtp:unix:private/dovecot-lmtp), and yields such a log line:
to=, relay=my.domain[private/dovecot-lmtp] ...
dsn=2.0.0, status=sent
But having "my.domain virtual:"; for instance, changes the log line to:
to=, relay=virtual ... dsn=2.0.0, status=sent
So the incoming email's domain /is/ matched against local_transport_map
and the transport described there is used.
### Test with randmap ###
transport_maps = hash:/etc/postfix/local_transport_map
randmap:{smtp:[relay1.com]:587, smtp:[relay2.com]:587}
Adding randmap after local_transport_map (unchanged "my.domain :" line)
results in all incoming email being relayed to one of the randmap relays.
Nico
OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: persistent log of sent emails?
On 24.02.22 20:23, Joachim Lindenberg wrote: I know that postfix writes to a log: However there is a lot of diagnostics in the standard log that I am not interested to keep for a longer period of time. Is there a way to tell postfix to write a distinct log of delivered emails (delivered = next hop, not necessarily destination)? postfix uses syslog by default, you can filter logs using syslog daemon. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them
Re: randmap getting precedence in transport_maps?
Nicolas JEAN:
> ### Tests without randmap ###
>
> transport_maps = hash:/etc/postfix/local_transport_map
>
> Having "my.domain :" or "my.domain lmtp:unix:private/dovecot-lmtp"
> doesn't modify default behaviour (set by virtual_transport =
> lmtp:unix:private/dovecot-lmtp), and yields such a log line:
> to=, relay=my.domain[private/dovecot-lmtp] ...
> dsn=2.0.0, status=sent
Note that you would get the exact same email delivery result with
a map that does not match your domain.
How would you tell the difference between a map that returns ":"
for your domain and a map that does not match your domain?
Not by looking at the mailog file.
> But having "my.domain virtual:"; for instance, changes the log line to:
>
> to=, relay=virtual ... dsn=2.0.0, status=sent
>
> So the incoming email's domain /is/ matched against local_transport_map
> and the transport described there is used.
This is a DIFFERENT map that matches your domain.
> ### Test with randmap ###
>
> transport_maps = hash:/etc/postfix/local_transport_map
> randmap:{smtp:[relay1.com]:587, smtp:[relay2.com]:587}
>
> Adding randmap after local_transport_map (unchanged "my.domain :" line)
We know based on the above test that THIS UNCHANGED MAP either
returns ":" for your domain or it does not match your domain.
And now we know the difference:
> results in all incoming email being relayed to one of the randmap relays.
Conclusion: the map does not match your local domain, and therefore
Postfix queries the next map, which is the randmap.
Wietse
Re: randmap getting precedence in transport_maps?
Em 24/02/2022 17:14, Wietse Venema escreveu:
Nicolas JEAN:
Having "my.domain :" or "my.domain lmtp:unix:private/dovecot-lmtp"
doesn't modify default behaviour (set by virtual_transport =
lmtp:unix:private/dovecot-lmtp), and yields such a log line:
to=, relay=my.domain[private/dovecot-lmtp] ...
dsn=2.0.0, status=sent
Note that you would get the exact same email delivery result with
a map that does not match your domain.
How would you tell the difference between a map that returns ":"
for your domain and a map that does not match your domain?
Not by looking at the mailog file.
Understood, good point.
But having "my.domain virtual:"; for instance, changes the log line to:
to=, relay=virtual ... dsn=2.0.0, status=sent
So the incoming email's domain /is/ matched against local_transport_map
and the transport described there is used.
This is a DIFFERENT map that matches your domain.
transport_maps = hash:/etc/postfix/local_transport_map
randmap:{smtp:[relay1.com]:587, smtp:[relay2.com]:587}
Tested: adding above randmap also 'supersedes' a local_transport_map
containing the domain-matching "my.domain virtual:"...
I don't understand how "my.domain :" and "my.domain virtual:" can have
different results, isn't it only the left part that matches incoming
emails' addresses? How would having ':' or 'virtual:' on the right side
change the matching?
OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: Looking for high skilled Postfix expert
On Thu, Feb 24, 2022 at 06:58:46PM -0300, Leandro Santiago wrote: > (please let me know if this message somehow goes against the list rules) It is borderline relevant, provided in practice such posts don't become frequent, and perhaps whatever you're working on might ultimately benefit the Postfix user community. > my startup is looking for a Postfix expert for consulting. We're > European based, but location is not a problem. I am not volunteering, but want to add that you should be explicit about whether you're looking for operational expertise (knowledge of advanced use-cases, strong familiary with Postfix integration with anti-spam, milters, IMAP, ...) or development expertise (familiarity with, and readiness to contribute to the Postfix source code). The latter category is fairly thinly populated, but there may well be list subscribers with a deep operational background who are in a position to help you. -- Viktor.
Looking for high skilled Postfix expert
Hi list, (please let me know if this message somehow goes against the list rules) my startup is looking for a Postfix expert for consulting. We're European based, but location is not a problem. We mainly develop open source software that integrates deeply with Postfix (and well, opendkim, dovecot and others), as well as using it as part of our infrastructure. If interested, please reply off-list. -- Regards, Leandro Santiago Software Craftsman at Lightmeter https://calendly.com/leandro-santiago https://lightmeter.io OpenPGP_0xAB5F702209190A96.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
mailer-daemon/bounce messages tagged as spam
Hi, I'm not sure if this is a postfix config problem or an amavis/SA problem. I have a multi-instance postfix config, and my mailer-daemon messages are being filtered by my amavisd/SA config, many of which are being quarantined as spam instead of being returned to the sender. Of course it's possible a spammer could craft a message that appears to be a bounce/failure report, but isn't a characteristic that they have a null envelope sender? I don't think my postfix config would even allow this unless it was part of an actual bounce? The messages are apparently being received on port 25 then being treated as regular messages instead of actual bounces. Shouldn't these undeliverable messages be determined before postfix finishes delivering the actual message? Feb 24 09:45:07 xavier postfix-116/smtpd[842535]: connect from mail-qb1can01hn2020.outbound.protection.outlook.com[52.100.145.20] Feb 24 09:45:08 xavier postfix-116/smtpd[842535]: 05D1E10002E4E: client=mail-qb1can01hn2020.outbound.protection.outlook.com[52.100.145.20] Feb 24 09:45:08 xavier postfix-116/cleanup[839994]: 05D1E10002E4E: message-id=<71b19f68-beae-4f20-ba7d-6c8cd374...@yqbpr0101mb6167.canprd01.prod.outlook.com> Feb 24 09:45:08 xavier postfix-116/qmgr[580062]: 05D1E10002E4E: from=<>, size=81447, nrcpt=2 (queue active) I was going to include some of my config, but I really don't know what to include. I suspect it's related to my transport configs, but I think they are pretty much the defaults. smtp_send_xforward_command = yes relay_transport = $default_transport local_transport = error:5.1.1 Mailbox unavailable virtual_transport = $default_transport Here's the master.cf config for amavisd: 127.0.0.1:10025 inet n - n - 16 smtpd -o content_filter= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8,209.216.00.0/24,209.216.99.153/29 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings -o local_header_rewrite_clients=
