[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.
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
