Transfer error?
AES
and instantly get a "Transfer Error" message back referring to just one
of these addresses (which I'd failed to note is obviously malformed),
does that mean the message was still sent to all the other recipients in
the list?
Patty Winter
In article <siegman-21E081...@bmedcfsc-srv02.tufts.ad.tufts.edu>,
I don't think so, but I've wondered the same thing. It would be easy
enough to test by sending a message with both yourself and an invalid
address as recipients.
Patty
John H Meyers
Only a message whose _every_ address is initially acceptable
to the SMTP server which Eudora directly contacts
will ever get to the point of having the deliverable message
be given to the SMTP server, hence the very first objection to any address,
during Eudora's on-line session with that SMTP server,
terminates all processing with _no_ sending at all.
This means that you should simply correct or remove the objectionable address
which "tripped the emergency brake and halted the entire train,"
and then attempt again to send the message. If another objection occurs this time,
perhaps to some other address, it's "back to the drawing board" all over again,
until there is no immediate objection to _any_ address at all.
This is because the basic SMTP protocol has two distinct phases:
In the first phase, a client (or intermediate server) first conveys
the sender's own (single) address ["MAIL FROM" command], followed by
to what addresses the deliverable message remains to be delivered,
submitted one at a time via a "RCPT TO" command, repeated so that
each address receives its own individual response from the server.
This phase is called the "envelope," and effectively
collects To/Cc/Bcc addresses, without distinction.
Then the sending side finally conveys (after a "DATA" command)
the object to actually be delivered to each recipient,
starting with the particular headers that you normally see and expect.
If the "envelope" phase results in a session being aborted,
as is the case with all common personal email clients,
where you are expected to be present while they are contacting
an initial SMTP server that directly handles user-submitted mailings,
then that session never gets to the point where a "DATA" command
(followed by the subsequent actual content to be delivered to recipients)
would occur, so that there's nothing that can possibly be delivered,
as of the point where the session is aborted by the client.
Since users of email clients are used to seeing entire lists of addresses
lumped together into headers, we carry around an impression that this
is how those recipient addresses are shipped off to an SMTP server,
but the headers actually take no part at all in the "envelope" phase,
where the client itself submits only one address at a time to the server,
accompanied by nothing else (no names, no commas, not even header names
such as "To" or "Cc" -- nothing but plain email addresses, one at a time)
Once the initial SMTP server which the client itself contacts
has initially accepted every address, and only then,
is the deliverable content presented, which the SMTP server
basically simply stores, doing only minimal processing
of a nature basically not caring very much
about the headers which you composed yourself.
After accepting that "deliverable content" package,
the session between client and initial server ends,
and from that point onward, you are no longer on-line to that server,
but have left your message "at the post office," which thereafter
takes all responsibility for trying to forward it towards its
eventual final domains and the end users (recipients) at those domains.
During subsequent contacts by your initial "message submission"
SMTP server with "message transfer" or "message delivery" servers
handling different domains, the same protocol is used,
but objections to remaining individual delivery addresses,
"peeled off" from the original "envelope" and submitted only
to servers ready to receive mail for individual domains,
result in the making of lists of rejected addresses,
continuing to processes all remaining addresses anyway.
If a list of rejected addresses was created, then that server
which is holding such a list composes a "bounce message"
to be sent back to the original sender (identified by the
original "MAIL FROM" command, and usually also inserted by a server
into a "Return-Path:" header), informing of the failure to deliver
to the list of rejected addresses, which gets queued and forwarded
in exactly the same manner as any other mail message.
Note that as mail (actually copies of the original mail) "fans out"
toward recipients dispersed across different domains,
the "peeled off" envelope, containing lists of remaining recipients,
keeps shrinking, while the deliverable original message does not.
That is, your originally composed "To:" header, for example,
still identifies people at all the original domains) -- that's
essentially why the "envelope" (or "routing slip") is completely
separate from the deliverable content, and why only the "envelope"
tells servers where to keep trying to forward the deliverable content
to the remaining addresses that haven't yet received the original package.
The entire system, basically analogous to postal mail, is thus very simple
(Simple Mail Transfer Protocol -- SMTP) and is intelligently designed
to separate _routing_ of the package from the _content_ of the package.
"Routing" info (MAIL FROM, RCPT TO, RCPT TO, RCPT TO ...)
comes first, and the deliverable package (DATA) comes last,
so if your initial session aborts on a bad routing address,
the rest of the train does not follow, and you must start over again.
A lot of credit must go to those brilliant designers who conceived
the entire system, which has scaled up from small beginnings
to the massive delivery of "packages" world-wide, often in just a few seconds,
with very little in the way of mishaps or losses, functioning so well
that we rarely even look into how it works, unless we need someone
to explain to us why no one else gets an aborted "send,"
and why we thus have to simply "send again" until it's initially accepted,
thus leaving each message with a simple status of either "sent" or "unsent,"
never with an unmanageable "sent to half the people
and need a re-send to the other half" :)
Image of a message on its way from original sender to a specific recipient,
using SMTP at each stage of the journey:
http://en.wikipedia.org/wiki/File:SMTP-transfer-model.svg
Image of a "bounce":
http://en.wikipedia.org/wiki/File:Bounce-DSN-MTA-names.png
More detailed "Anatomy of a bounce":
http://en.wikipedia.org/wiki/Bounce_message
This is obviously too complex for a personal email client
to do for itself, which is why they simply abort,
while you are on hand to make the individual correction(s),
one at a time, and simply "re-send the whole message."
--