Re: Usefullness of reject_rbl_client in recipient restrictions

From: Simon J Mudd (no email)
Date: Sat Nov 01 2003 - 05:26:28 EST


 (Tony Earnshaw) writes:

> Noel Jones wrote:
>
> >> One cannot put specific client, helo, sender (including restriction
> >> classes) or data restrictions under recipient_restrictions. The
> >> former are called at different stages of the smtp transaction.
> > Of course you can.
> > ANY restrictions legal under smtpd_(client|helo|sender)_restrictions
> > can be used under smtpd_recipient_restrictions and will work
> > correctly.
>
> Looking back at your posting, I see you mention that both the tidy and
> untidy method of entering restrictions are supported.
>
> However, rules are carried out in the exact above sequence - client,
> helo, sender, recipient, data.
>
> It's not at all a good idea put restriction into the wrong sequence;
> specific client restrictions apply to the client sequence,
> etc. permit_mynetworks put into the client restrictions does not have
> the same effect as permit_mynetworks in the recipient sequence. Sender
> restrictions are not the same as recipient restrictions. What on earth
> would one be thinking of if one were to put helo restrictions into
> recipient restrictions?
>
> The value of keeping restrictions logically separated by class makes
> debugging that much easier. 'tail -f'ing the Postfix log and scrolling
> back in a 4096 line X terminal is an excellent debug help and moreover
> aids in learning exactly what Postfix is doing. Rules entered in an
> illogical order are confusing and can lead to the wrong conclusions
> being drawn.

The reason for putting ALL the restrictions in the final stage is that
initially (vmailer days I think) Postfix rejected immediately after
each stage and therefore if you blocked at the HELO stage you did not
have any information about who the recipient OR the sender was. This
made it much more difficult to identify problems, and also contact the
originator of the message (if necessary).

Performing all the checks later on when you have all the information
available makes the log file more complete and it easier to fix
problems, block the sender, ... or perform whatever action you wish.

So yes, it's clearer to have the restrictions separated into different
categories, though many people still use the "put it all at the end"
style which may appear counter intuitive at first. Perhaps the naming
of smtpd_recipient_restrictions is not really appropriate when used
this way, though changing the name now seems more hassle than it's
worth.

Perhaps a short explanation in uce.html would make things clearer for
everyone of why some people use the smtpd_XXX_restrictions in a
non-counterintuitive manner.

Simon








Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD