https://bugs.exim.org/show_bug.cgi?id=1788
--- Comment #16 from Alex Presland <exim@???> ---
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
user@???. Here's the (even more complex) email path for
user1@???
[1] Email presented to server for delivery to first.last@???
[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
filtered-first.last@??? to a delivery to the localuser1 account.
[5] The localuser1 account requests two significant deliveries: "deliver
localuser1" and "deliver user@???"
That said, I've provided examples previously where it doesn't go through a
local user's account
I've now got an alex@??? address, and have requested a
alex@??? 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 alex@???
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
(first1.last1@??? 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.
