From: Mark Plomer (mailit-plomer.de)
Date: Sun Jun 24 2007 - 10:54:18 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi List,
I am doing a setup for my customers where all spam mails can be
delivered to separate mailboxes. So I planned the following setup:
1. The first Postfix instance does no address rewriting
(receive_override_options = no_address_mappings)
2. Mail is delivered to amavisd-new, which adds "+spam" address
extension, if spam is detected, and reinjects mail into Postfix' second
instance.
3. The second Postfix instance does address rewriting
So long, but now I have the following questions:

For example the following virtual alias table (in a MySQL database) is
given:
  infodomain.xyz -> maildomain.xyz
  maildomain.xyz -> maildomain.xyz (-> Maildir)
  mail+spamdomain.xyz -> mail+spamdomain.xyz (-> Maildir)

  testdomain.xyz -> testexternal-domain.xyz

  domain.xyz -> maildomain.xyz

And the following relevant option is set:
propagate_unmatched_extensions = virtual

Now there are three possible scenarios: If amavisd-new sends mail back to:
1. info+spamdomain.xyz -> is mapped to mail+spamdomain.xyz, which IS
what I like
2. test+spamdomain.xyz -> is mapped to test+spamexternal-domain.xyz,
which is NOT what I like (I like it to be mapped to
testexternal-domain.xyz, because the external domain has problems with
the extension, of course)
3. catchall+spamdomain.xyz -> is mapped to maildomain.xyz, which is
NOT what I like (I like it to be mapped to mail+spamdomain.xyz, because
spam separation for the catchall-alias does not work otherwise)

Point 2: propagate_unmatched_extensions can only be globally set. Is
there any possibility to only propagate extensions, if the _destination_
domain (of the lookup result) is in $mydestionation, $transport_maps,
$virtual_mailbox_domains, ... ? The other solution is, that I turn off
"propagate_unmatched_extensions" and autogenerate additional entries
like "info+spamdomain.xyz -> mail+spamdomain.xyz" for aliases which
destination is internal, so this works for Point 1 an 2. This is ok for
me, but it would be great, if there is a Postfix-only solution ;-)

Point 3: The catchall-problem. I have seen Wietse's comment at:
http://groups.google.com/group/list.postfix.users/browse_thread/thread/509d6e6a3672cd29/aa6d7b70336f14bf?lnk=gst&q=catch-all+address-extension&rnum=1#aa6d7b70336f14bf
But how would you combine the regex lookups with the MySQL lookups?
First I have to generate all regex'es for all domains, that have
catchall activated. But the regex matches on the first postfix query, so
if I send mail to test+spamdomain.xyz, the regex-catchall matches and
the address is mapped to maildomain.xyz, instead of matching the entry
"testdomain.xyz".

Here an idea for a Postfix-only solution:
What about an option to activate an additional lookup, so the following
lookups are done:
- user+extdomain.xyz
- userdomain.xyz
- user+ext
- user
- +extdomain.xyz <-- With this additional query, I think the problem
can be solved
- domain.xyz
So I can add an entry like "+spamdomain.xyz -> mail+spamdomain.xyz"

Another Postfix-only solution:
What about an option to propagate the address extension also to
"catchall"-entries?

The third idea is to work with STORED PROCEDURES in MySQL, but actually
I can't return result sets from stored procedures to Postfix, and I have
no skills with stored procedures, so I can't guess, if this is a solution.

The fourth idea is: Do the address mapping in the first postfix
instance, so amavisd adds the extension to the already resolved address,
but then I have to let amavisd know, if the domains are internal or
external (to add the extension only to internal domains), and eventually
this has some additional side effects like double resolved addresses, ....

Does anyone have some additional ideas or comments to this, to do a
further step into a spam free world? ;-)

Best regards
Mark Plomer

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]