[Pushing this back onto the list thread, because someone who actually
uses Amavis with Exim is likely to have more insight into the issue than me]
On 22/03/11 17:07, Dave Shariff Yadallee - System Administrator a.k.a.
The Root of the Problem wrote:
> On Tue, Mar 22, 2011 at 01:51:08PM +0000, Dominic Benson wrote:
>> OK, well from the mainlog, it looks to me like every so often you get a
>> timeout connecting to amavis (on localhost), and then follow
>> R=amavis T=amavis defer (-53): retry time not reached for any host
>> for a number of messages. That essentially means that no deliveries take
>> place for some minutes until the condition clears.
>>
>> The maillog is still transferrring, I'm only getting a few KB/s from your
>> FTP server. That might highlight why the errors arise, but in any case, you
>> should specify a retry time for localhost
>> (http://www.exim.org/exim-html-3.20/doc/html/spec_33.html) to stop the big
>> gaps in delivery. I think that will make a fairly substantial difference.
>> You should at least be able to increase the proportion of time your machine
>> spends actually relaying mail. (Or do your AV/Spam checks purely in Exim,
>> exim is pretty capable at such things and it really cuts down on the total
>> number of SMTP transactions and gross effort. This would be more effective,
>> but if you have specialist requirements may not be possible).
>>
> Ah! Yes!
>
> I did update the retry to
>
> begin retry
>
> # This single retry rule applies to all domains and all errors. It specifies
> # retries every 15 minutes for 1 hours, then increasing retry intervals,
> # starting at 1 hour and increasing each time by a factor of 1.5, up to 10
> # hours, then retries every 1 hours until 7 days have passed since the first
> # failed delivery.
>
> # WARNING: If you do not have any retry rules at all (this section of the
> # configuration is non-existent or empty), Exim will not do any retries of
> # messages that fail to get delivered at the first attempt. The effect will
> # be to treat temporary errors as permanent. Therefore, DO NOT remove this
> # retry rule unless you really don't want any retries.
>
> # Address or Domain Error Retries
> # ----------------- ----- -------
>
> ##* * F,1h,15m; G,10h,1h,1.5; F,7d,1h
> * * F,1h,5m; G,10h,1h,1.5; F,2d,1h
>
> I might want something 'draconian' but will reread the
> retry documentation.
>
> Next
>
> #############################################################################
>
> # Accept mail to postmaster in any local domain, regardless of the source,
> # and without verifying the sender.
>
> accept local_parts = postmaster
> domains = +local_domains
>
> # Deny unless the sender address can be verified.
>
> ##require verify = sender
> accept domains = +local_domains
> endpass
>
> ## Sender Verify on 'Recipient'
>
> drop message = REJECTED - Sender Verify Failed - error code \"$sender_verify_
> failure\"\n\n\
> The return address you are using for this email message<$sender_address>\
> does not seem to be a working account.
> log_message = REJECTED - Sender Verify Failed - error code \"$sender_ver
> ify_failure\"
> !hosts = +no_verify
> !verify = sender/callout=2m,defer_ok
> condition = ${if eq{recipient}{$sender_verify_failure}}
>
> ## Sender verify failed and no REverse DNS
>
> drop message = REJECTED - Sender Verify Failed and no RDNS
> log_message = REJECTED - Sender Verify Failed and no RDNS
> !verify = reverse_host_lookup
> !verify = sender/callout=2m,defer_ok
> !condition = ${if eq{$sender_verify_failure}{}}
>
> ## Recipient Verification
>
> deny message = REJECTED - Recipient Verify Failed - User Not Found
> domains = +all_mail_handled_locally
> !verify = recipient/callout=2m,defer_ok,use_sender
>
> ## Too many failed recipients
>
> warn domains = +local_domains
> !verify = recipient
> set acl_c0 = ${eval: $acl_c0+1}
> delay = ${eval: ($acl_c0 - 1) * 60}s
>
> NOte the ##require verify = sender
>
> I had to turn that off because legit virtual e-mail was
> getting nicked. How do I get this so that
> both virtual and non-virtual are properly recognised ?
It boils down to how Exim would route the message. If the sender verify
was going through Amavis and getting a temp error, then as that doesn't
have defer_ok, it might have been rejected for that. I'm not sure, to be
honest.
Can you avoid the problem by accepting authenticated first? Hopefully
someone else will have a clearer idea of the solution.
