Lisa Muir wrote: > On Fri, Jan 30, 2009 at 7:02 AM, Gordon Messmer <[email protected]> wrote: >> >> Most mail client will stop if a recipient is rejected. They will >> indicate the error to the user and allow (or require) the address to be >> corrected before the message is sent. > > Until the next "send / receive" frequency time occurs. If a user walks > away for a week, any MUA i have experience of will happily resubmit > the message say every 30 mins for the entire week.
You and I must have no overlapping experience. I've never seen a mail client do that. > No, it was on the auto send/receive frequency. > > In the old days a message would get accepted and bounce. That depends on the nature of the failure. My mail server will happily accept a message from me for a non-existent address, as long as the address isn't local to the server. If the address is local to the server, then the server will inform the client if the address isn't valid. The server will also refuse to accept email addresses which aren't well formed (missing an "@", for instance). > Now, it is > being accepted for some recipients, but the message delivery to the > MTA fails, and thus interpreted by the MUA as not having being > accepted at all. You've lost me completely. What does "delivery to the MTA fails" mean, exactly? > Either the MUA must now intelligently interpret the error and queue > the message for the failing recipients only, or the MTA must not > return a failure for the message, There's (at least) a third option, which is the way most clients that I can think of will follow: if the server rejects any RCPT commands, indicating that an address is bad, the client will notify the user and not send the message. > its simply illogical to reject a > message during a submit to an MTA and then have the MTA deliver it > anyway for some subset of the original distribution list. I don't think you understand what we've tried to explain. Delivery isn't a single operation. A desktop mail client (or any other smtp client) connects to the server and sends "HELO" (or EHLO). It verifies that the command succeeds. It sends "MAIL FROM" and verifies that the command succeeds. It sends "RCPT TO" for each address (To, CC, and BCC), and verifies that each individual command succeeds. Finally, it sends "DATA" and verifies that the command succeeds. If so, it sends the message body, and verifies that the command succeeds. It is in no way difficult to handle the event of a RCPT command failing. It is also not illogical for the protocol to allow a RCPT to fail, but the remainder of the recipients receive the message. Every sender has the same options: either track the delivery status of each RCPT or bail out on any failure. Whatever is going wrong with the client you're describing is not a server problem. It will happen with any SMTP server. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
