Problem with virtual_alias_maps and backscatter
Hi,
I got 2 domains, let's call them example.org and example.com and i want
them to share the same mail addresses. So f...@example.org and
f...@example.com should always reach the same destination.
The mail system consists of 2 MX hosts and a single backend MTA that
forwards all mails to my imap server. The MX hosts use virtual_domains
and virtual_alias_maps to check whether a specific recipient exists and
then forward the mail to the internal host or in some cases to external
mail servers.
For years now the virtual_alias_map for example.org and example.com
looked like this:
/^(.*)@example\.com$/${1}@example.org
/^foo@example\.org$/ f...@some-other-domain.org
/^bar@example\.org$/ bar@external-domain.something
This worked just fine but, for some reason only now, i realized this
makes @example.com a backscatter spam source.
Re-reading the documentation over and over again i yesterday realized
that a simple non-regexp table containing
@example.com@example.org
...
does suffice to do the same thing. However the problem i'm having stays
the same.
Looking into the source code the reason for this behaviour is that,
while the virtual_alias_maps lookup as done by the cleanup daemon is
recursive the same lookup by smtpd is not. It will simple except
anything that is a match in any of the various lookup tables (just
search for 'virt_alias_maps' in smtpd/smtpd-check.c to find the code i'm
referring to).
For now the problem is not too severe since example.com is not used
often and the whole mail system has very low traffic. So any massive
misuse of the system would have triggered my monitoring.
Still this is not a situation that i want to keep any longer and even
worse i recently had to do a similiar setup for somebody else. The
premise is basically the same only that for this system addresses for
mails to example.org are resolved using an LDAP lookup and the mail
system uses virtual_mailbox_maps to filter non existing users. This
domain will be used much more frequently and will soon attract spammers.
So my first question is whether the above analysis is correct?
If yes i think the documention doesn't state well enough that this is
the case. For me it is obvious that in case the virtual alias is
pointing to an external address it will not be checked but i was
surprised to have the same behaviour for addresses that are handled by
the same MTA. Especially since the documentation explicitly says that
the lookups in virtual_alias_maps are recursive.
And of course my next question: How can i change my setup to make it
work without turning my MX hosts to backscatter spam sources?
For the originial system i of course can use a regexp lookup that looks
something like this:
/^foo@example\.(org|com)$/ f...@some-other-domain.org
/^bar@example\.(org|com)$/ bar@external-domain.something
This is what i will be doing as soon as i finished writing this mail. Of
course for the other system this is not as easy. The only thing i can
think of right now is to have a cron script that generates a
virtual_alias_map for example.com based on the LDAP entries for
example.org. Is this really the only way or is there another solution to
this?
regards
christian
signature.asc
Description: OpenPGP digital signature
Re: Problem with virtual_alias_maps and backscatter
equinox:
> Re-reading the documentation over and over again i yesterday realized
> that a simple non-regexp table containing
>
>
> @example.com@example.org
> ...
>
>
> does suffice to do the same thing. However the problem i'm having stays
> the same.
Indeed. With Postfix 2.4 and later, both the virtual(5) and
canonical(5) manpages document that wildcard address mappings will
break adress validation.
Address validation in the SMTP daemon was not part of the initial
Postfix design, and therefore the validation will be an over-approximation
when a map replaces an address. To be more precise, the lookup
result would have to go through all the steps that are implemented
in the cleanup daemon.
Currently, you can make the address validation more precise with:
- Replace the @example.com - @example.org mapping with a 1:1 alias
for each valid address in example.com.
- Keep the @example.com - @example.org mapping, and add a
reject_unverified_recipient check for recipients in example.com.
unverified_recipient_reject_code = 550
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access inline:{example.com=reject_unverified_recipient}
The inline: table is available in Postfix 3.0 and later. Use a
hash: map with earlier Postfix versions.
The reject_unverified_recipient feature requests that the verify(8)
daemon sends a probe email message to find out of the recipient
address would bounce (after RCPT TO, Postfix sends RSET and QUIT).
The probe message result is cached for several days, so the number
of probes per recipient will be small.
If the alias (or canonical mapping) resolves to a remote address,
Postfix will contact a remote server. If this happens a lot then
the remote site might object.
Wietse
Re: How to setup a mailbox clone
Paul Richards: > Can I just use: > #in /etc/postfix/main.cf > virtual_alias_maps = hash:/etc/postfix/domain_copy.conf > > #in /etc/postfix/domain_copy.conf > @mydomain.edu @host1.mydomain.edu @host2.mydomain.edu This should not loop, because you are not sending @host1.mydomain.edu to @host2.mydomain.edu or vice versa. However, the use of wildcards breaks address validation. See today's email thread "Problem with virtual_alias_maps and backscatter" for possible remediation. That said, I think that the replicated message store would be the better approach because the replication enforces consistency. Wietse
Re: Problem with virtual_alias_maps and backscatter
Hi,
Am 20.05.2018 um 16:40 schrieb Wietse Venema:
[...]
> Indeed. With Postfix 2.4 and later, both the virtual(5) and
> canonical(5) manpages document that wildcard address mappings will
> break adress validation.
>
Yes i read that but as said was surprised that this included lookups to
the very same table as well. Especially since lookups to
virtual_alias_map are docuemented to be recursive. Of course after
reading the source code and seeing where all this is done it got very
clear to me why postfix is doing it the way it does.
However i still think the documentation should be more specific about this.
[...]
>
> - Keep the @example.com - @example.org mapping, and add a
> reject_unverified_recipient check for recipients in example.com.
>
> unverified_recipient_reject_code = 550
> smtpd_recipient_restrictions =
> ...
> reject_unauth_destination
> check_recipient_access inline:{example.com=reject_unverified_recipient}
That did the trick! Thanks for the fast response!
regards
christian
signature.asc
Description: OpenPGP digital signature
Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')
On 5/17/2018 3:20 PM, Wietse Venema wrote: Wietse Venema: deoren: /etc/postfix/sender-access.cf: # First, a rule that matches health-check mail. smtp-health-che...@example.com DUNNO # Add a BCC recipient to other email. * BCC f...@example.com For the last entry that BCC's "everything else", is the * character a valid source? The access map syntax is documented. http://www.postfix.org/access.5.html There is no '*' in there. If you must filter on sender address, you can use a regexp: or pcre: table. smtpd_xxx_restrictions = ... check_sender_access pcre:/etc/postfix/sender-access.pcre ... /etc/postfix/sender-access.pcre: # First, a rule that matches health-check mail. /^smtp-health-checks@example\.com$/ DUNNO # Add a BCC recipient to other email. . BCC f...@example.com The ^, $, \, and . are special only when you use regexp: or pcre:. They are not part of the access map syntax. Instead of the above pair of rules you could use if..endif, but again, those are not part of the access map syntax, but of the specific lookup table. Wietse Thank you for your help. Re the '*' syntax, I wasn't sure how to accomplish the goal of matching everything, so thanks for clearing that up. I ended up going with this setup based off of your feedback and the original example I found from Victor Duchovni: /etc/postfix/main.cf # BCC mail flowing through this relay EXCEPT for # health check emails for future troubleshooting pcre:/etc/postfix/auto_bcc.pcre # Other checks/actions proxy:mysql:/etc/postfix/mysql-sender_access.cf, /etc/postfix/auto_bcc.pcre # though this content is indented to stand out # there is no indention in the file itself if !/^haproxy-smtp-check@example\.com$/ /@/ BCC arch...@example.com endif So far it appears to be working just fine. Thanks again for your help.
Mail being delayed for 5 minutes in active queue before being relayed
Hi there, I've set up a mail server that should be relaying messages to a different cluster of Postfix boxes. When I attempt to send a message to the first box, mail sits in the active queue for 5 minutes before being (successfully) relayed to the cluster of Postfix boxes. which is then delivered correctly. I'm trying to figure out why this is and have it relay immediately (as expected). *My box I'm attempting to relay FROM is on: * *Here's my (sanitized) postconf -n:* Thanks for your help. -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: How to setup a mailbox clone
On 20 May 2018, at 09:23, Wietse Venema wrote: > That said, I think that the replicated message store would be the > better approach because the replication enforces consistency. This thread is starting to feel like one of those "I want to do X but I don’t want to do (Thing specifically designed to do X) and instead want to do (something I thought up that I want to work). Can anyone help me” threads. -- I'm not old, I'm chronologically challenged.
Re: openDKIM and postfix
> On May 20, 2018, at 7:24 PM, John Levine wrote: > > Has anyone actually seen it happen in the > wild in the past decade? I have a dataset with ~1.4 million MX hosts. Running through those at a gentle pace (one at a time) after the first ~200 MX hosts I have 10 that don't announce 8BITMIME. So it certainly happens. Whether there's anyone behind those MTAs looking at DKIM is a rather different question... --- mail.webbrowserbellen.be posttls-finger: Connected to mail.webbrowserbellen.be[109.236.95.78]:25 posttls-finger: < 220 HELO welcome to smtp.voipcentrale.nl posttls-finger: > EHLO amnesiac posttls-finger: < 250-hollanddns.com [192.0.2.1], this server offers 2 extensions posttls-finger: < 250-SIZE 5120 posttls-finger: < 250 HELP posttls-finger: > QUIT posttls-finger: < 221 Service closing transmission channel --- mail.octowood.nl posttls-finger: Connected to mail.octowood.nl[79.170.91.81]:25 posttls-finger: < 220 server1.adnecto.dk ESMTP Exim 4.72 Mon, 21 May 2018 01:39:35 +0200 posttls-finger: > EHLO amnesiac posttls-finger: < 250-server1.adnecto.dk Hello amnesiac [192.0.2.1] posttls-finger: < 250-SIZE 20971520 posttls-finger: < 250-PIPELINING posttls-finger: < 250-AUTH PLAIN LOGIN posttls-finger: < 250-STARTTLS posttls-finger: < 250 HELP posttls-finger: > QUIT posttls-finger: < 221 server1.adnecto.dk closing connection --- rouge.insel-zu-verkaufen.de posttls-finger: Connected to rouge.insel-zu-verkaufen.de[213.32.119.109]:25 posttls-finger: < 220 insel-zu-verkaufen.de ESMTP ready posttls-finger: > EHLO amnesiac posttls-finger: < 250-hello amnesiac posttls-finger: < 250-PIPELINING posttls-finger: < 250 SIZE 10485760 posttls-finger: > QUIT posttls-finger: < 221 insel-zu-verkaufen.de --- mail.fuis.nl posttls-finger: Connected to mail.fuis.nl[5.200.9.113]:25 posttls-finger: < 220 mailcluster.webhosting-manager.nl ESMTP posttls-finger: > EHLO amnesiac posttls-finger: < 250-mailcluster.webhosting-manager.nl posttls-finger: < 250-SIZE 5000 posttls-finger: < 250-AUTH LOGIN posttls-finger: < 250 HELP posttls-finger: > QUIT posttls-finger: < 221 goodbye --- bierboetiek.com posttls-finger: Connected to bierboetiek.com[80.69.95.175]:25 posttls-finger: < 220 WEB03.home ESMTP MailEnable Service, Version: 8.51-- ready at 05/21/18 01:47:15 posttls-finger: > EHLO amnesiac posttls-finger: < 250-home [192.0.2.1], this server offers 4 extensions posttls-finger: < 250-AUTH LOGIN posttls-finger: < 250-SIZE 1536 posttls-finger: < 250-HELP posttls-finger: < 250 AUTH=LOGIN posttls-finger: > QUIT posttls-finger: < 221 Service closing transmission channel --- mail.finwize.nl posttls-finger: Connected to mail.finwize.nl[77.72.147.81]:25 posttls-finger: < 220 s01.finwizewebhost.nl ESMTP Exim 4.76 Mon, 21 May 2018 01:48:22 +0200 posttls-finger: > EHLO amnesiac posttls-finger: < 250-s01.finwizewebhost.nl Hello amnesiac [192.0.2.1] posttls-finger: < 250-SIZE 31457280 posttls-finger: < 250-PIPELINING posttls-finger: < 250-AUTH PLAIN LOGIN posttls-finger: < 250-STARTTLS posttls-finger: < 250 HELP posttls-finger: > QUIT posttls-finger: < 221 s01.finwizewebhost.nl closing connection --- mail.literaircafehelmond.nl posttls-finger: Connected to mail.literaircafehelmond.nl[95.211.201.5]:25 posttls-finger: < 220 mail.mkbportal.nu ESMTP MailEnable Service, Version: 9.00-9.00- ready at 05/21/18 01:49:15 posttls-finger: > EHLO amnesiac posttls-finger: < 250-mkbportal.nu [192.0.2.1], this server offers 4 extensions posttls-finger: < 250-AUTH LOGIN posttls-finger: < 250-SIZE 4096 posttls-finger: < 250-HELP posttls-finger: < 250 AUTH=LOGIN posttls-finger: > QUIT posttls-finger: < 221 Service closing transmission channel --- vrouwzoekt.nl posttls-finger: Connected to vrouwzoekt.nl[149.210.159.235]:25 posttls-finger: < 220 stickyservers.nl ESMTP Exim 4.76 Mon, 21 May 2018 01:50:42 +0200 posttls-finger: > EHLO amnesiac posttls-finger: < 250-stickyservers.nl Hello amnesiac [192.0.2.1] posttls-finger: < 250-SIZE 20971520 posttls-finger: < 250-PIPELINING posttls-finger: < 250-AUTH PLAIN LOGIN posttls-finger: < 250-STARTTLS posttls-finger: < 250 HELP posttls-finger: > QUIT posttls-finger: < 221 stickyservers.nl closing connection --- moczni.hu posttls-finger: Connected to moczni.hu[212.52.166.43]:25 posttls-finger: < 220 2-Narasimha.hu V2.08 antispam service. Please keep in mind, we decline spams! posttls-finger: > EHLO amnesiac posttls-finger: < 250-Welcome, 192.168.14.20 [192.168.14.20], pleased to meet you posttls-finger: < 250-AUTH=LOGIN posttls-finger: < 250-AUTH LOGIN posttls-finger: < 250 HELP posttls-finger: > QUIT posttls-finger: < 221 Aba he --- herbanow.com posttls-finger: Connected to herbanow.com[149.210.188.57]:25 posttls-finger: < 220 server.markbruin.nl ESMTP Exim 4.76 Mon, 21 May 2018 01:51:42 +0200 posttls-finger: > EHLO amnesiac posttls-finger: < 250-server.markbruin.nl Hello amnesiac [192.0.2.1] posttls-finger: < 250-SIZE 20971520 posttls-finger: < 250-PIPELINING posttls-finger: < 250-AUTH
Re: openDKIM and postfix
> On May 20, 2018, at 7:59 PM, Viktor Dukhovni > wrote: > > I have a dataset with ~1.4 million MX hosts. Running through those > at a gentle pace (one at a time) after the first ~200 MX hosts I have > 10 that don't announce 8BITMIME. I stopped the scan after 2308 MX hosts of which 72 did not offer 8BITMIME. The purported Exim versions were: 1 4.63 2 4.69 5 4.72 1 4.73 19 4.76 1 4.77 The next most common non-8bit MTAs were 12 instances of "MailEnable Service". -- Viktor.
