What might cause a user to receive duplicate emails?

Question

One of our customers is receiving duplicate emails from our application, even though as far as I can tell from the application and SMTP logs, we're only sending it out once.

What are some of the ways that an email might be duplicated between sending it out and receiving it?

Some more details: the emails are being sent via IIS6. The duplicates that the user receives really are exact duplicates, right down the message headers (including the same Message-ID). There's no apparent duplication in the SMTP source logs - I'm not a sys admin myself so I don't have much experience with these, but it seems normal:

2012-02-16 17:54:45 127.0.0.1 portal PORTAL 127.0.0.1 MAIL +FROM:<[email protected]> 250 0 59 46
2012-02-16 17:54:45 127.0.0.1 portal PORTAL 127.0.0.1 RCPT +TO:<[email protected]> 250 0 33 30
2012-02-16 17:54:45 127.0.0.1 portal PORTAL 127.0.0.1 DATA <[email protected]> 250 0 140 10654

and then (I assume) the response from the target mail server itself a few lines later:

2012-02-16 17:54:45 208.186.207.146 OutboundConnectionResponse PORTAL - - 220+smtp.redacted.com+ESMTP+Service+ready 0 0 41 0
2012-02-16 17:54:45 208.186.207.146 OutboundConnectionCommand PORTAL - EHLO portal.mycompany.com 0 0 4 0
2012-02-16 17:54:45 208.186.207.146 OutboundConnectionResponse PORTAL - - 250-Requested+mail+action+okay,+completed 0 0 41 0
2012-02-16 17:54:45 208.186.207.146 OutboundConnectionCommand PORTAL - MAIL FROM:<[email protected]>+SIZE=10998 0 0 4 0
2012-02-16 17:54:45 208.186.207.146 OutboundConnectionResponse PORTAL - - 250+Requested+mail+action+okay,+completed 0 0 41 0
2012-02-16 17:54:45 208.186.207.146 OutboundConnectionCommand PORTAL - RCPT TO:<[email protected]> 0 0 4 0
2012-02-16 17:54:46 208.186.207.146 OutboundConnectionResponse PORTAL - - 250+Requested+mail+action+okay,+completed 0 0 41 0
2012-02-16 17:54:46 208.186.207.146 OutboundConnectionCommand PORTAL - DATA - 0 0 4 0
2012-02-16 17:54:46 208.186.207.146 OutboundConnectionResponse PORTAL - - 354+Start+mail+input;+end+with+<CRLF>.<CRLF> 0 0 44 0

(…then it takes a few seconds until…)

2012-02-16 17:54:50 208.186.207.146 OutboundConnectionResponse PORTAL - - 250+Requested+mail+action+okay,+completed 0 0 41 0
2012-02-16 17:54:50 208.186.207.146 OutboundConnectionCommand PORTAL - RSET - 0 0 4 0
2012-02-16 17:54:50 208.186.207.146 OutboundConnectionResponse PORTAL - - 250+Requested+mail+action+okay,+completed 0 0 41 0

Solution 1

The client's email server may have certain rules in it ("Transport Rules" is the nomenclature if it's an Exchange server) that are inexplicably duplicating your inbound email. You'll need to bring this issue up with the client.

Also, the client's email program may have simple inbox rules that have poor logic. I've seen more than a few email issues that were as a result of a poorly designed mail client rule that inadvertently duplicate, moved or deleted email that it wasn't intended to.

Solution 2

There are two cases where I have seen this.

• Message is delivered to more than one alias at different times or as different messages. This happens a lot for me as I use lots of aliases. Check the headers for message id which should be different. The original address may be included in a received header or the envelope to header if present.
• A server accepted the message for delivery, but the server sending to it doesn't get the accept message. It retries. In this case the message id header will have the same value, but the received headers will differ. The server where the received headers start differing is where the problem started. In my experience this has been a firewall timing out the connection too quickly.

In either case you need the message headers to diagnose the problem.

Comments

[Wesley]

When you say "customer" are you referring to an individual recipient mailbox or does "customer" refer to an entire organization and each mailbox for that organization's domain is receiving duplicate emails?

[Gavin]

Only received a complaint from one user, but it's possible other recipients in the same company just haven't piped up about it. But I guess your point is that the answer would help to determine if, for example, it's a mail server issue or a local inbox rule issue.