[exim-dev] [Bug 1788] Some deliveries not re-attempted after…

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumptes vells: [exim-dev] [Bug 1788] New: Deliveries to one ISP sometimes fail silently after T=remote_smtp defer on first delivery attempt
Assumpte: [exim-dev] [Bug 1788] Some deliveries not re-attempted after 'T=remote_smtp defer (-53): retry time not reached for any host' on first delivery attempt
https://bugs.exim.org/show_bug.cgi?id=1788

--- Comment #5 from Alex Presland <exim@???> ---
Hi Jeremy. Thanks again for your prompt response.

Thanks to the link about the asterisk. That's good to know that it is
efficiently using the existing connection.

The log snippet that I gave for 1aQLXt-0006xu-N5 is fully accurate, except for
the fact that I removed a few deliveries to reduce the amount of anonymising
that I had to do. The other deliveries were to Tiscali, Yahoo and an
independent host; they were all delivered successfully and indicated by a '=>'
on their log lines.

Having looked at
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html#SECTwhelogwri,
I did a "exim -bP | grep -i log", which indicated to me that Exim is doing the
logging directly, rather than through syslog. The details returned from this
are:

check_log_inodes = 0
check_log_space = 0
hosts_connection_nolog =
log_file_path = /var/log/exim4/%slog
log_selector = +tls_peerdn
no_log_timezone
message_logs
no_preserve_message_logs
process_log_path = /var/spool/exim4/exim-process.info
smtp_connect_backlog = 20
syslog_duplication
syslog_facility =
syslog_processname = exim
syslog_timestamp
unknown_login =
write_rejectlog

I can confirm that I get mainlog, rejectlog and paniclog in /var/log/exim4/
(plus rotated versions thereof). Paniclog is empty and therefore not rotated.

When I talk about the retry queue, I'm talking about the queue visible through
running 'mailq', which I understand is actually the spool files that can be
found in /var/spool/exim4/. Running "exim -bP | grep -i spool" gives:

check_spool_inodes = 0
check_spool_space = 0
process_log_path = /var/spool/exim4/exim-process.info
smtp_check_spool_space
no_split_spool_directory
spool_directory = /var/spool/exim4

Other than a few minor tweaks of the default Debain package config, the server
is running vanilla confirmation.  The tweaks that I've made are:
* Adding a relay host into /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt
* (currently commented out, so not active) Added a smarthost for all non-local
outbound traffic, in /etc/exim4/conf.d/router/200_exim4-config_primary.  This
was added as when building this server, my host gave me an IP address that was
on spam blacklists, so I temporarily routed all outbound SMTP traffic through
the old server as a smarthost.  It has been disabled since moving to the
server's current (clean) IP address.
* Added a config file /etc/exim4/conf.d/main/10_local_max_conns, due to
historical overloading from a single host, containing:
      smtp_accept_max = 100
      smtp_accept_max_per_host = 10
* Tweaks in /etc/exim4/sa-exim.conf (SpamAssassin)
  -> Added the IP address of a single host to bypass SpamAssassin
     checking (as it was already done) to "SAEximRunCond: ..."
  -> Changed spam threshold "SAdevnull: 10.0"
  -> Changed spam save condition "SAdevnullSavCond: 0"
  -> Commented out "SApermreject: ..." as this mucks up scanning of
     emails received via fetchmail/


I have requested specific confirmation for message 1aQLXt-0006xu-N5 to
"user@???", and will confirm back when I receive it. I chose
this message as it was the most recent.

I've had many confirmations of missing emails for the emails sent to
"user@???", who was the user that originally reported
messages going missing.

No logs are available from PlusNet, as I haven't engaged them. I wouldn't
expect that PlusNet would be much help. If you need, I can set up some log
monitoring and a tcpdump for traffic to mx.avasin.plus.net's IP addresses... in
order to catch the next time that this happens.

I'm currently thinking / guessing that it is just coincidence that the 'lost'
emails are all destined for mx.avasin.plus.net, but has occurred due to the
number of aliases that point to different PlusNet-hosted email addresses (and
probably also its reliability to receive emails, which is causing the defers).

--
You are receiving this mail because:
You are on the CC list for the bug.