Sam, et al,

Here's a situation that happened recently.  I posted to a popular
mailing list and courieresmtp logged the following.

Aug 19 20:12:06 shakti courieresmtp: 
id=000000000027586D.0000000050318EDD.00006F31,from=<[email protected]>,addr=<[email protected]>:
 450-4.3.2 Service currently unavailable
Aug 19 20:12:06 shakti courieresmtp: 
id=000000000027586D.0000000050318EDD.00006F31,from=<[email protected]>,addr=<[email protected]>:
 450 4.3.2 Contact your postmaster/admin for assistance. Please provide the 
following information in your problem report: time (A...
Aug 19 20:12:06 shakti courieresmtp: 
id=000000000027586D.0000000050318EDD.00006F31,from=<[email protected]>,addr=<[email protected]>,status:
 deferred

The connecting server at python.org returned a temporary error.
Apparently Courier queued this email for redelivery, and the MUA
(Evolution) noted the failure and apparently left the problem email in
my Outbox.  A minute later, the MUA tried again, successfully:

Aug 19 20:13:10 shakti courieresmtp: 
id=00000000002758BD.0000000050318F21.00006FAC,from=<[email protected]>,addr=<[email protected]>:
 250 2.0.0 Ok: queued as 3X0cTL2xBFzQM6
Aug 19 20:13:10 shakti courieresmtp: 
id=00000000002758BD.0000000050318F21.00006FAC,from=<[email protected]>,addr=<[email protected]>,size=4147,success:
 delivered: mail.python.org [82.94.164.166]
Aug 19 20:13:10 shakti courieresmtp: 
id=00000000002758BD.0000000050318F21.00006FAC,from=<[email protected]>,addr=<[email protected]>,size=4147,status:
 success

Note the different Message ID.

Five minutes later, Courier tried, again successfully, to deliver _its_
queued copy of the message.  Note that the Message ID is identical to
that of the original deferred post.

Aug 19 20:17:08 shakti courieresmtp: 
id=000000000027586D.0000000050318EDD.00006F31,from=<[email protected]>,addr=<[email protected]>:
 250 2.0.0 Ok: queued as 3X0cYw1CRlzQ6g
Aug 19 20:17:08 shakti courieresmtp: 
id=000000000027586D.0000000050318EDD.00006F31,from=<[email protected]>,addr=<[email protected]>,size=4147,success:
 delivered: mail.python.org [82.94.164.166]
Aug 19 20:17:08 shakti courieresmtp: 
id=000000000027586D.0000000050318EDD.00006F31,from=<[email protected]>,addr=<[email protected]>,size=4147,status:
 success

The end result was that although I only posted once, two copies of my
post were delivered to the list, and to all list subscribers.

I've had some discussion with two of the primary developers of the
Mailman list server package, Mark Sapiro and Brad Knowles.  Mark replied
as follows below. "shakti" is running Courier 0.64.0:

"And therein lies the problem. It appears the mail server (shatki) is
configured to attempt delivery to the next hop MTA before returning
status to the sender. This in itself is not bad and can result in the
sender receiving an error status during SMTP rather than the
problematic accept the message and later return a failure DSN to the
possibly spoofed envelope sender of the message. This can be a good
thing.

"However, the problem in this case is shatki received a 450 status from
python.org and possibly both queued the message for retry and reported
the 450 to the sender. This will result in a duplicate if the sender
retries the 450.

"I think if shatki is going to report the 450 to the sender during SMTP,
it should not retry the send itself.

"Otherwise, if it is going to retry, it should either report success to
the sender and later send a DSN to the envelope sender if delivery
ultimately fails or keep the SMTP session with the sender open and
only report status when it gets a 2yz or 5yz response from the next
hop. Probably only the former is viable as the latter would likely
result in the session with the sender timing out before completion."
-----

My question is this.  If a receiving SMTP server returns a temporary
failure, what should Courier's response be?  Should it assume that the
requesting MUA will queue the post and retry, or should it return
success to the MUA and retry from its own queue.  Neither alternative
seems to be satisfactory.  Is the MUA at fault here for queuing the
message and retrying?  This doesn't seem logical.

What's the fix? 

-- 
Lindsay Haisley       | "Fighting against human creativity is like 
FMP Computer Services |   trying to eradicate dandelions"
512-259-1190          |
http://www.fmp.com    |       -- Pamela Jones


------------------------------------------------------------------------------
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
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to