https://bugs.exim.org/show_bug.cgi?id=1788
--- Comment #5 from Alex Presland <[email protected]> --- 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 "[email protected]", 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 "[email protected]", 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
