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.
