Lindsay Haisley writes:
On Wed, 2012-08-22 at 06:57 -0400, Sam Varshavchik wrote: > Lindsay Haisley writes: > > > The headers you sent reflect this. It looks as if Mailman on your end > > didn't cancel the held message, or it was moderated through as I was > > canceling it. > > You also cc-ed your reply to me, the copy that I got was the CC copy.Please accept my apology. I know it's bad form to CC a poster when replying to a list post. I always try to cover this base, but sometimes I slip up. This is doubtless how the duplicate came through to you. I hope it's a non-issue going forward and I'll try to be more careful.
Oh, I wasn't complaining, by no means! I was just explaining what happened here, that's all.
There's no reason to be more careful.
* For some reason, which we don't know, _MUA_ caches the msg, probably in the outbox, and sends it successfully a minute later. Courier considers this a new message and assigns new msg ID ending in FAC.
Yeah, it must've been something along those lines. For some reason the MUA believed that it was not able to send the message, so it queued it up and tried again later.
Which, in the grand scheme of things, is not a wrong thing to do. If the MUA thought that it failed to connect to the mail server and send a message, it's reasonable for it to try again later.
But, one minor weakness in SMTP is that after sending a message, and waiting for the receiving mail server to respond, if there's a network issue the sender then fails to get the ack, and doesn't really know if the message was received, or not. It might very well be that it was, but some network failure somewhere along the line prevented the sender from receiving the acknowledgement.
So, with the sender doesn't really have a way of knowing what happened, the sender will rightfully assume – and it would be the correct choice – that it failed, and will try again later.
If this is a one-off situation, then I would also write it off as a one-off; although it would be very unusual to have this happen on a LAN.
Note that this /can/ happen to Courier too, if it tries to send the message, does not get a response, and the connection drops. Courier will presume it's a failure, and try again.
Were this to happen, the receipient would've gotten multiple copies too, but the initial set of headers, the Date: header, and Courier's Received: headers would've been identical on both copies, and only the recipient's Received: headers differing, showing it as receiving both copies of the message several minutes apart.
And, your Courier logs would've logged the first attempt's presumed connection failure.
pgpQUld6kdnLJ.pgp
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
