Re: balsa+libesmtp bug

[Brian Stafford <brian stafford uklinux net>]

On Fri,  4 May 15:42 Carlos Morgado wrote:

| > Having said that however, it is possible undeliverable recipients
| > will be accepted and queued by the MTA which will subsequently send
| > a non-delivery notification (bounce) when it fails to locate MX/A
| > records for the recipient's domain.
| > 
| 
| That is NotOurProblem(tm) :) and in fact we can't do anything about it
| so once the MTA accepts the message for delivery we're in the clear
| imho.

True.  If an MTA accepts a recipient with a 2xx status and accepts the
message with a 2xx response to the DATA command, then it has assumed
responsibility for delivering the message to that recipient.

I was really making the point that the MTA behaviour might affect
the success/failure presentation in the client when sending the
message.

| > The reason I don't like the idea of not sending to accepted
| recipients
| > when others fail is that when transient (4xx) errors occur and
| > two recipients are alternating between success and transient
| failure,
| > sending the message at all may become unnecessarily difficult.
| > 
| Right. remember the status of each explicit recipient seems the 
| best aproach. however, do we treat To: and Cc: equaly ? that is, 
| do we send to Ccs if a To adress fails ? Rationale is, Cc: are people
| who should also get the message but are not the primary recipients, so
| should them get it if the primary recipient(s) can't ? 

My gut feeling is that all recipients are equal. The To/Cc/Bcc
is just informational context to whoever is reading the message.

| is there any rule ? 

Bcc: (or Resent-Bcc:) can be in the message according to
RFC 822, which says this

     4.5.3.  BCC / RESENT-BCC

        This field contains the identity of additional  recipients  of
        the  message.   The contents of this field are not included in
        copies of the message sent to the primary and secondary  reci-
        pients.   Some  systems  may choose to include the text of the
        "Bcc" field only in the author(s)'s  copy,  while  others  may
        also include it in the text sent to all those indicated in the
        "Bcc" list.

According to RFC 821 an MTA can only add a Received: at the top
of a message when it relays or delivers the message.

To be correct according to the two rules above, the message would
need to be submitted twice, once to the recipients who get to see
the Bcc: list, and once to the recipients who don't with the Bcc:
header absent.  I'd bet good money that some MTA out there (most
likely a misconfigured sendmail) will strip it though (and thus
violate RFC 821).

Maybe this sort of thing might be a nice feature to have, but
I guess its more complexity than is needed and that it is unlikely
to work as expected


| any unspoken rule ? opinions ? :)

None I know of.  I'd just say they are all equal.  Ultimately,
if a recipient fails and that is reported to the user, the user
will decide whether to retry or abandon that recipient based on
the circumstances at that time.  Put another way, decent reporting
is probably more useful than automatic assumptions.

Brian Stafford