Lindsay Haisley writes:
OK, a little work with tcpdump and swaks clarified how things actually work. The designated SMTP server for the MUA engages in _two_ SMTP dialogs, one with them MUA and one with the recipient mail server.
I'm quite skeptical that this is the case. There's no reason for the MUA to contact different mail servers.
Is there any possibility that Courier, when relaying, might hold open the connection with a requesting MUA until the connection with the recipient server is complete, and return something to the MUA accordingly?
No, I know of no mail server that would do that, in a smarthost capacity. This would defeat the entire purpose of having a mail server. A MUA might as well look up MX records itself, and attempt to connect to the recipient domain's mail servers itself. A dedicated mail server would bring no value- added benefit.
That's the whole point for having some configuration setting in your MUA that says "here's the mail server": to have the mail server accept your MUA's outgoing mail immediately, and then proceed and make delivery attempts as many times as it's necessary, until the recipient's mail server accepts the message. That's what a mail server does.
In particular, is there any difference in the behavior of
Courier when a recipient server returns a 450 tempfail, as opposed to a
451 code?
Nope. The only thing that Courier, and any other sane mail server does is discriminate between 4xx and 5xx class errors. The individual error codes are just a logging curiosity.
> > A minute later, the MUA tried again, successfully: > > > > Aug 19 20:13:10 shakti courieresmtp: id=00000000002758BD. > > 0000000050318F21.00006FAC,from=<fmouse-mail...@fmp.com>,addr=<mailman- > > us...@python.org>: 250 2.0.0 Ok: queued as 3X0cTL2xBFzQM6 > > Aug 19 20:13:10 shakti courieresmtp: id=00000000002758BD. > > 0000000050318F21.00006FAC,from=<fmouse-mail...@fmp.com>,addr=<mailman- > > us...@python.org>,size=4147,success: delivered: mail.python.org > > [82.94.164.166] > > Aug 19 20:13:10 shakti courieresmtp: id=00000000002758BD. > > 0000000050318F21.00006FAC,from=<fmouse-mail...@fmp.com>,addr=<mailman- > > us...@python.org>,size=4147,status: success > > This is Courier sending a different message. This is not your MUA. Well I suspect it _was_ the MUA which inserted this since this message was identical in all respects to the previous one, except for the assigned message ID, and the list subscribers received two identical posts from me. The message IDs back this up. I'm very fond of my chosen MUA, Evolution, which is nearly as powerful for mail management as some of the old CLI mail programs such as Mutt. T-bird can't touch it, although with recent improvements it's getting there. Evolution does, however, have "issues", which is probably a good part of the reason it's no longer the default MUA for recent versions of Ubuntu Linux.
It is not unheard for the MUA to send a second copy of the message, if for some reason it reached the conclusion that the first time failed.
Examining the full headers of both copies of the supposedly duplicated message, with an explicit focus on all the timestamps, should clear this up.
pgpMMSTsuTLyh.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
