On 08/25/2012 04:11 PM, Gordon Messmer wrote: > On 08/22/2012 03:30 PM, Lindsay Haisley wrote: >> I don't know what other insights can be gained by reading the headers or >> log entries. I consider this a closed case at this point and won't >> bother this list with further analysis of it. On the off chance that >> you or Gordon_do_ find something I've missed, please post and I'll >> revisit it. I have no idea why Evolution sent the same email twice. > > No, I think your understanding of the situation is basically correct. > The logs that you posted included the courieresmtp client, but not the > courieresmtpd/courierd messages that record accepting the message from > the client. However, it's unlikely that those would tell you much more. > I'm mostly sure that courier would only send the message on to the > list if it told the client "250 ok". > > There is at least one open bug in Evolution that causes it to duplicate > messages in the Outbox. Your situation could be similar: > https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/825194
Sorry to be late on commenting here. and I may be 100% off target, but this is worth mentioning I believe. A VPN was mentioned and OFTEN creates major hassles for normal TCP old school transactions (ftp, smtp, etc) in that MTU (maximum size of a packet) discovery is nearly always broken, and never matches the de facto default LAN 1500byte MTU due to VPN's added headers/overhead. PMTU discovery allows end to end TCP sessions to have a exact max MTU size of choke points (i.e. smaller MTU's in intermediate links...including VPNs) and avoid such problems. I've seen hundreds of applications work very well on a LAN and falter on VPN's for exactly that reason. Note that more modern (streaming) apps utilize a UDP stream and small tcp management stream to wrap the entire experience, but rely heavily upon application awareness to mitigate such problems and do manipulate MTU's but at the application layer. Well worth checking out. This combined with various OS and application implementations may result in a real duplicate attempt to send a message (packetized sequenced bundles of data) when a first attempt fails. Thus, the client, client/server OS's, server, and intermediate/adjunct programs can often fail mid transaction due to missing bytes over a VPN. You might try manually reducing the MTU on the client side or the MUA side to say 1400 bytes (very negligible performance impact) and see if you can "non" repeat the situation. I'm guessing this might be the case. In managing a commercial multimillion user mail system, we set the MTU well below 1000 bytes, and cut our customer service calls in half, but that was more than a decade ago. Good luck, andy ------------------------------------------------------------------------------ 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
