> 
> Yes, that will work fine if you put your check_sender_access rule under 
> smtpd_data_restrictions.
> 

I am unsure if that works. I thought that check_sender_access only uses the 
envelope-from tag. So where is the difference between putting it in 
smtpd_recipient_restrictions or waiting for the end of the DATA phase? Think, I 
don't understand :-)

MAIL FROM:<whate...@example.org>
220 OK
RCPT TO:<....>   <-- Testing here, if in smtpd_recipient_restrictions
220 OK
RCPT TO:<....>   <-- and again, producing the duplicate??
220 OK
DATA
.<CR><LF> <-- Testing after this point, if in smtpd_data_restrictions. But does 
this behave differently then the above?

>> So I thought I need a different method and configured header_checks:
>> 
>> # header_checks
>> 
>> if !/^VBR-Info:.*roessner-net(work-solutions)?/
>> /^From:....@roessner-net\.com/                 PREPEND VBR-Info: 
>> md=roessner-net.com; mv=dwl.spamhaus.org; mc=all
>> /^From:....@roessner-network-solutions\.com/   PREPEND VBR-Info: 
>> md=roessner-network-solutions.com; mv=dwl.spamhaus.org; mc=all
>> endif
> 
> Headers are checked one at a time with no state kept, so the above will never 
> work.  Put your check_sender_access rule in smtpd_data_restrictions.
> 
The rules shown above are for header_checks. That seems to do the trick, but I 
have to add no_header_body_checks to the receive_overide_options in the return 
socket. Unfortunately this also disables header checking for incoming MTA 
connections. I would need a different return socket for amavis, but I do not 
know how to tell amavis in its policy_banks to use a different 
forward-/notify-method :-( So this is something I asked on the amavis-users 
list right now.

Christian

Reply via email to