processing order lookup tables

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

processing order lookup tables

gerrit-14
Hi All,

Recently i implemented the sender check. First i made a split for the
processing and put some restrictions under smtpd_sender_restrictions and
some under stmpd_recipient_restrictions.

This resulted in too many rejections, so i left the sender restrictions
emtpy and put all under the recipient restrictions.


smtpd_helo_restrictions =
                reject_invalid_hostname
                reject_non_fqdn_hostname

smtpd_sender_restrictions =

smtpd_recipient_restrictions =
                reject_non_fqdn_recipient
                reject_non_fqdn_sender
                reject_unknown_sender_domain
                reject_unknown_recipient_domain
                permit_mynetworks
                check_sender_access hash:/etc/postfix/sender_whitelist
                check_recipient_access hash:/etc/postfix/recipient_whitelist
                reject_unauth_destination
                reject_unverified_sender

One question is now : In which order are the sender restrictions and
recipient restrictions applied ?  So when a mail comes in, are first all
the rules applied from the recipient restrictions and
then the sender restrictions or just the other way ?




Another question :

The mailserver (latest centos version 2.3.3) does virtual mailbox hosting.
I have a few "catch-all" network wide email adresses : postmaster@,
apache@ and some more.  My goal is, if there isn't a explicit (real)
mailbox for a postmaster in a domain, then this catch-all has to catch
those mails.
But... Since i forward these now, i put a table under
virtual_alias_maps. But when a real mailbox is defined, the mail is
picked up by the virtual_alias_maps first since the processing order is
first virtual_alias_maps and then virtual_mailbox_maps.. Right ?

Is there any way to work around this ?  Putting the table with these
regular expressions under virtual_mailbox_maps at the end isn't a
solution, because this mapping does a mailbox lookup instead of
forwarding.  Note : the mail are forwarded to a mailbox which is hosted
on the same server.


Regards,
Gerrit



Reply | Threaded
Open this post in threaded view
|

Re: processing order lookup tables

mouss-2
gerrit wrote:

> Hi All,
>
> Recently i implemented the sender check. First i made a split for the
> processing and put some restrictions under smtpd_sender_restrictions and
> some under stmpd_recipient_restrictions.
>
> This resulted in too many rejections, so i left the sender restrictions
> emtpy and put all under the recipient restrictions.
>
>
> smtpd_helo_restrictions =
>                reject_invalid_hostname
>                reject_non_fqdn_hostname
>
> smtpd_sender_restrictions =
>
> smtpd_recipient_restrictions =
>                reject_non_fqdn_recipient
>                reject_non_fqdn_sender
>                reject_unknown_sender_domain
>                reject_unknown_recipient_domain
>                permit_mynetworks

put
        reject_unauth_destination
here. never put reject_unauth_destination after maps that return OK
based on easily forged information (such as sender).

>                check_sender_access hash:/etc/postfix/sender_whitelist
>                check_recipient_access hash:/etc/postfix/recipient_whitelist
>                reject_unauth_destination
>                reject_unverified_sender

sender verification callbacks are not very appreciated. many people
consider them abusive. now every time a spammer hits your server with a
forged sender, you're hitting an innocent server. and you don't even
have anti-spam checks to mitigate this.

>
> One question is now : In which order are the sender restrictions and
> recipient restrictions applied ?  So when a mail comes in, are first all
> the rules applied from the recipient restrictions and
> then the sender restrictions or just the other way ?
>

the other way, but why do you care? put all your restrictions under
smtpd_recipient_restrictions so that you don't need to repeat permit_*
checks.


>
>
>
> Another question :
>
> The mailserver (latest centos version 2.3.3) does virtual mailbox hosting.
> I have a few "catch-all" network wide email adresses : postmaster@,
> apache@ and some more.  My goal is, if there isn't a explicit (real)
> mailbox for a postmaster in a domain, then this catch-all has to catch
> those mails.
> But... Since i forward these now, i put a table under
> virtual_alias_maps. But when a real mailbox is defined, the mail is
> picked up by the virtual_alias_maps first since the processing order is
> first virtual_alias_maps and then virtual_mailbox_maps.. Right ?

it's catch all, not catch some :)

you need to add "identity mappings" to your virtual_alias_maps:
[hidden email] [hidden email]
...

so that they don't get redirected to your catchall aliases.

>
> Is there any way to work around this ?  Putting the table with these
> regular expressions under virtual_mailbox_maps at the end isn't a
> solution, because this mapping does a mailbox lookup instead of
> forwarding.  Note : the mail are forwarded to a mailbox which is hosted
> on the same server.

Reply | Threaded
Open this post in threaded view
|

Re: processing order lookup tables

gerrit-14
mouss schreef:

> gerrit wrote:
>> Hi All,
>>
>> Recently i implemented the sender check. First i made a split for the
>> processing and put some restrictions under smtpd_sender_restrictions
>> and some under stmpd_recipient_restrictions.
>>
>> This resulted in too many rejections, so i left the sender
>> restrictions emtpy and put all under the recipient restrictions.
>>
>>
>> smtpd_helo_restrictions =
>>                reject_invalid_hostname
>>                reject_non_fqdn_hostname
>>
>> smtpd_sender_restrictions =
>>
>> smtpd_recipient_restrictions =
>>                reject_non_fqdn_recipient
>>                reject_non_fqdn_sender
>>                reject_unknown_sender_domain
>>                reject_unknown_recipient_domain
>>                permit_mynetworks
>
> put
>     reject_unauth_destination
> here. never put reject_unauth_destination after maps that return OK
> based on easily forged information (such as sender).
Ok.. thank you. It's all very new to me. and sometimes not all is clear.
But i want to learn things... and that's worth much ;)

>
>>                check_sender_access hash:/etc/postfix/sender_whitelist
>>                check_recipient_access
>> hash:/etc/postfix/recipient_whitelist
>>                reject_unauth_destination
>>                reject_unverified_sender
>
> sender verification callbacks are not very appreciated. many people
> consider them abusive. now every time a spammer hits your server with
> a forged sender, you're hitting an innocent server. and you don't even
> have anti-spam checks to mitigate this.
The name maybe a bit misleading. For some domains or email adresses, you
have to whitelist them. Since this is done locally, eg. postfix doesn't
have to do a query over the internet to check them, this would be the
fair way i guess.
Not every one does have a fully RFC compliant mailserver, yet i try to
have one. :D

The only thing i'm saying in those maps is : permit the request, if an
email address matches a entry in that file.


>
>>
>> One question is now : In which order are the sender restrictions and
>> recipient restrictions applied ?  So when a mail comes in, are first
>> all the rules applied from the recipient restrictions and
>> then the sender restrictions or just the other way ?
>>
>
> the other way, but why do you care? put all your restrictions under
> smtpd_recipient_restrictions so that you don't need to repeat permit_*
> checks.
>
>
>>
>>
>>
>> Another question :
>>
>> The mailserver (latest centos version 2.3.3) does virtual mailbox
>> hosting.
>> I have a few "catch-all" network wide email adresses : postmaster@,
>> apache@ and some more.  My goal is, if there isn't a explicit (real)
>> mailbox for a postmaster in a domain, then this catch-all has to
>> catch those mails.
>> But... Since i forward these now, i put a table under
>> virtual_alias_maps. But when a real mailbox is defined, the mail is
>> picked up by the virtual_alias_maps first since the processing order
>> is first virtual_alias_maps and then virtual_mailbox_maps.. Right ?
>
> it's catch all, not catch some :)
>
> you need to add "identity mappings" to your virtual_alias_maps:
> [hidden email]    [hidden email]
> ...
>
> so that they don't get redirected to your catchall aliases.
Yet...  I know this method. But i dont wanna put (in total) 8000
mappings in a file with only postmaster@<somedomain> and abuse@
apache@.   Therefor i wanted to use the regex way.

This is what i have now in my main.cf  ( see the reserved_address
mapping file) :


virtual_mailbox_domains =  mysql:/etc/postfix/mysql-transport.cf

virtual_mailbox_maps =  mysql:/etc/postfix/mysql-mailbox.cf

virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
                     mysql:/etc/postfix/mysql-autoreply.cf
                     regexp:/etc/postfix/reserved-addresses



So my goal is to get this ( i hope i'm clear to everyone) :

virtual_mailbox_maps =  mysql:/etc/postfix/mysql-mailbox.cf
                                           
regexp:/etc/postfix/reserved-addresses

virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
                     mysql:/etc/postfix/mysql-autoreply.cf


In words :
If one of the "reserved_adresses" like apache@, postmaster@ don't exist
in virtual_alias_maps and the virtual_mailbox_maps, it has to be
"catched" by the reserved_addresses map which contains entries like  
^postmaster@   or '^abuse@'
Because the virtual_alias_maps are searched before the
virtual_mailbox_maps, i want to have the mapping there, under
virtual_mailbox_maps.
But... virtual_mailbox_maps expects an email => homedirectory mapping.  
And my wish is to have an email => alias mapping.

Can this be accomplished ?



Reply | Threaded
Open this post in threaded view
|

Re: processing order lookup tables

mouss-2
gerrit wrote:

>
>>>                check_sender_access hash:/etc/postfix/sender_whitelist
>>>                check_recipient_access
>>> hash:/etc/postfix/recipient_whitelist
>>>                reject_unauth_destination
>>>                reject_unverified_sender
>>
>> sender verification callbacks are not very appreciated. many people
>> consider them abusive. now every time a spammer hits your server with
>> a forged sender, you're hitting an innocent server. and you don't even
>> have anti-spam checks to mitigate this.
> The name maybe a bit misleading. For some domains or email adresses, you
> have to whitelist them. Since this is done locally, eg. postfix doesn't
> have to do a query over the internet to check them, this would be the
> fair way i guess.
> Not every one does have a fully RFC compliant mailserver, yet i try to
> have one. :D
>
> The only thing i'm saying in those maps is : permit the request, if an
> email address matches a entry in that file.
>

The problem is with reject_unverified_sender, not check_mumble_access.


>
>>
>>>
>>> One question is now : In which order are the sender restrictions and
>>> recipient restrictions applied ?  So when a mail comes in, are first
>>> all the rules applied from the recipient restrictions and
>>> then the sender restrictions or just the other way ?
>>>
>>
>> the other way, but why do you care? put all your restrictions under
>> smtpd_recipient_restrictions so that you don't need to repeat permit_*
>> checks.
>>
>>
>>>
>>>
>>>
>>> Another question :
>>>
>>> The mailserver (latest centos version 2.3.3) does virtual mailbox
>>> hosting.
>>> I have a few "catch-all" network wide email adresses : postmaster@,
>>> apache@ and some more.  My goal is, if there isn't a explicit (real)
>>> mailbox for a postmaster in a domain, then this catch-all has to
>>> catch those mails.
>>> But... Since i forward these now, i put a table under
>>> virtual_alias_maps. But when a real mailbox is defined, the mail is
>>> picked up by the virtual_alias_maps first since the processing order
>>> is first virtual_alias_maps and then virtual_mailbox_maps.. Right ?
>>
>> it's catch all, not catch some :)
>>
>> you need to add "identity mappings" to your virtual_alias_maps:
>> [hidden email]    [hidden email]
>> ...
>>
>> so that they don't get redirected to your catchall aliases.
> Yet...  I know this method. But i dont wanna put (in total) 8000
> mappings in a file with only postmaster@<somedomain> and abuse@
> apache@.   Therefor i wanted to use the regex way.

why regex? you are using mysql, so let mysql do it. just write a query
that returns what you want. the identity mapping is trivial in mysql (it
amounts to something like: select email from Email where email = '%s'
and ...) and lookup for postmaster and friends isn't harder.



>
> This is what i have now in my main.cf  ( see the reserved_address
> mapping file) :
>
>
> virtual_mailbox_domains =  mysql:/etc/postfix/mysql-transport.cf
>
> virtual_mailbox_maps =  mysql:/etc/postfix/mysql-mailbox.cf
>
> virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
>                     mysql:/etc/postfix/mysql-autoreply.cf
>                     regexp:/etc/postfix/reserved-addresses
>
>
>
> So my goal is to get this ( i hope i'm clear to everyone) :
>
> virtual_mailbox_maps =  mysql:/etc/postfix/mysql-mailbox.cf
>                                          
> regexp:/etc/postfix/reserved-addresses
>
> virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
>                     mysql:/etc/postfix/mysql-autoreply.cf
>
>
> In words :
> If one of the "reserved_adresses" like apache@, postmaster@ don't exist
> in virtual_alias_maps and the virtual_mailbox_maps, it has to be
> "catched" by the reserved_addresses map which contains entries like  
> ^postmaster@   or '^abuse@'
> Because the virtual_alias_maps are searched before the
> virtual_mailbox_maps, i want to have the mapping there, under
> virtual_mailbox_maps.

virtual_mailbox_maps is for virtual mailboxes. you can of course create
a mailbox for postmaster@*. but this is not the same thing as a virtual
alias.

> But... virtual_mailbox_maps expects an email => homedirectory mapping.  
> And my wish is to have an email => alias mapping.
>
> Can this be accomplished ?
>


again, you need the identity mapping. just let mysql do it for you.

virtual_alias_maps =
        proxy:mysql:/....
        proxy:mysql:/....
        proxy:mysql:/.../identity.cf
        proxy:mysql:/.../default_alias.cf


the identity.cf returns its key if the key is found. default_alias.cf
implements catchall.