https://bugs.exim.org/show_bug.cgi?id=1788
--- Comment #16 from Alex Presland <[email protected]> --- The tcpdump showed the expected establishment of a TCP connection and then SMTP exchange, including close-down. The only think that suprised me a little was Wireshark saying that the data fragements were sometimes being sent out of order (on the one larger email where the two messages went missing), and that there was some re-transmission. However, I believe that to all be at the TCP stack level and TCP doing what it does to get the whole message to the other end. What the tcpdump did show was that there were no delivery attempts when the queue runner kicked in, which matches the log file. There are two filter files involved in these deliveries, and they're extensive. I'll have a look at providing these, while protecting my customers' privacy. Back on 2016-02-07 01:02:19 GMT, I summarised the email path for [email protected]. Here's the (even more complex) email path for [email protected] [1] Email presented to server for delivery to [email protected] [2] The domain1.org.uk alias file sends the email to the 'spamcatcher' user account. This account's purpose is to stop spam from being relayed by the server, and thus protect its reputation. [3] The 'spamcatcher' user account applies a load of Exim Filter commands via its .foward file. If the email isn't quarantined / discarded, it is delivered to "filtered-$original_local_part@$original_domain". Thus, it is presented back to the domain1.org.uk alias file. [4] The alias file for domain1.org.uk translates [email protected] to a delivery to the localuser1 account. [5] The localuser1 account requests two significant deliveries: "deliver localuser1" and "deliver [email protected]" That said, I've provided examples previously where it doesn't go through a local user's account I've now got an [email protected] address, and have requested a [email protected] address from another customer, so that I can do more testing without affecting the actual users directly. It should be easy enough for me to get the queue status with messages queued. To look at the queue, I normally run the 'mailq' command, which I believe to be the same as running '/usr/sbin/exim4 -bp'. Is there a command that gives a more detailed diagnostic output, which you'd like me to use instead? I'll also have a go at recreating this in a number of scenarios: 1) Direct to the [email protected] 2) Via the domain1.org.uk alias file, with a single translation 3) Via the domain1.org.uk alias file and the 'spamcatcher' user account 4) Via the domain1.org.uk alias file, the 'spamcatcher' user account, and back out through the domain1.org.uk alias file again. I believe that what I see in the mailq output is the original email address ([email protected] and no others), but I'll capture this to give a definitive answer. If an email address is fed in directly, it will be delivered directly using the default remote_smtp transport. The "indirection" only occurs through alias files and user accounts' .forward files. -- 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/ ##
