https://bugs.exim.org/show_bug.cgi?id=2693
Bug ID: 2693
Summary: pipelining: exim messes up order of replies to RCPT TO
Product: Exim
Version: N/A
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Mail Receipt
Assignee: unallocated@???
Reporter: bp@???
CC: exim-dev@???
Dear Devs
I was chasing a problem, which happens when EXIM is sending an email to Postfix
with a couple of recipients, some of them tempfailing and pipelining activated.
Observed issue:
Some tempfailed recipients were not re-queued and exim showed them as being
successfully delivered to in the logs.
Some recipients, to which the email was successfully delivered, got re-queued
on the exim side and were then delivered a duplicate of the email.
Sniffing the transaction which causes the problem hints that there is an issue
with pipelining and exim not assigning the result codes of the RCPT TO commands
to the appropriate recipients.
Example pipelining transaction expalining the issue
EXIM > POSTFIX
MAIL FROM: S
RCPT TO: A
RCPT TO: B
RCPT TO: C
RCPT TO: D
RCPT TO: E
RCPT TO: F
EXIM < POSTFIX
250 2.1.0 OK
250 2.1.5 OK
250 2.1.5 OK
452 4.5.3 Please try again later
452 4.5.3 Please try again later
250 2.1.5 OK
250 2.1.5 OK
With pipelining, the ORDER of the result MUST correspond to the ORDER to which
re commands have been given.
So in the above example, the recipients C + D tempfailed and should be
re-queued by EXIM.
Observed: EXIM logs C + D as successfully delivered and Re-Queues E + F
C + D never get the email. E + F get duplicates.
PM me for a pcap file showing the issue (real customer data in it so not
attaching to this bug report).
=== Additional Information, why is Postfix tempfailing certain recipients? ===
It's by design of our spamfiltering implementation (which violates RFC5321 but
hopefully this RFC will be replaced by a new one to allow this kind of behavior
as it is the most sensible way to do it).
Guidelines of our spamfilter:
1. An email shall never disappear. If an email was successfully accepted by the
MTA, it has to be delivered to the recipients mailbox(es). If an event prevents
the email to be delivered, it has to be rejected during SMTP Handshake.
2. Backscatter / late bounces shall be avoided wherever possible.
Now assume two recipients: One has disabled the spam filter, the other one not.
During the recipients phase of the smtp handshake, we don't know the content of
the email, therefore we don't know if it will be classified by spam after the
DATA phase.
If it is spam and one recipient has disabled the spam filter and another not,
we can not reject the email for one recipient and accept the email for the
other one without breaking our guidelines.
Therefore, we have to make sure that all subsequent recipients have the same
spam settings as the first one. If this is the case, we accept the recipient,
if not, we tempfail the recipient with error 452 which corresponds to 'too many
recipients' causing the sending MTA to re-queue those recipients and usually
immediately retry then in a new session.
-Benoît-
--
You are receiving this mail because:
You are on the CC list for the bug.
