Problem with virtual_alias_maps and backscatter

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with virtual_alias_maps and backscatter

equinox
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 [hidden email] and
[hidden email] 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:

<snip>
/^(.*)@example\.com$/    ${1}@example.org
/^foo@example\.org$/     [hidden email]
/^bar@example\.org$/     [hidden email]
</snip>

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

<snip>
@example.com    @example.org
...
</snip>

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:

<snip>
/^foo@example\.(org|com)$/     [hidden email]
/^bar@example\.(org|com)$/     [hidden email]
</snip>

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 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with virtual_alias_maps and backscatter

Wietse Venema
equinox:

> Re-reading the documentation over and over again i yesterday realized
> that a simple non-regexp table containing
>
> <snip>
> @example.com    @example.org
> ...
> </snip>
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with virtual_alias_maps and backscatter

equinox
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 (817 bytes) Download Attachment