Gary wrote:

> Gary wrote:

>>> > If I knew how much confusion the semantics of bypass_*  vs.  *_lovers
>>> > is causing, I would have provide only _lovers, and derive bypass_
>>> > automatically from it. Perhaps some day...

>> Mark, are you saying you want to automatically assign all *lovers to
>> bypass*? Then how would you accomplish this?:

>> bypass lover
>>   0      1     useful, check but deliver tagged

> Am I correct to say that this also would no longer be possible?:

> @spam_lovers_maps = (1);
> @bypass_spam_checks_maps = ( [ qw( [EMAIL PROTECTED] [EMAIL PROTECTED] 
> .example2.com ) ],);

> I just not getting how this idea could work in all cases.

I think part of the problem was the OP wanted to bypass spam checks,
but was really configuring the wrong table to do this, and therefore
confused the issue. In his case, it just happened to work out that the
same *lovers table he configured could be used as a bypass* table. I
think we agree that it is a good idea that if a recipient is in a
bypass* table, that same recipient should be in the corresponding
*lovers table. The reverse of course only applies in some cases and
limits the flexibility of the *lovers table.

I was on the postfix list a while ago and it mentioned that the
transport map could server double duty by setting:
relay_domains = $transport_maps

Magnus rightfully responded:

"No, that' a bad idea. What happens if you need to add some domain that
you do not host to transport_maps (say, hotmail.com) and do not pay
proper attention to the fact that the same map is used for several
purposes? Instant open relay!"

So, in practice I think the same philosophy may apply here. It may be
better to keep tables that serve different purposes separate.

Gary V



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Reply via email to