I cannot imagine that what you present as a reason for sending back
message bodies is a plausible or common scenario in 2003.
How many protocols do we have that - at the application layer - send
back the whole request when things don't work out? Imagine if you
were to abort an FTP upload and got a copy of the whole file back "so
you know which one failed"!
You're saying that sender must
.. send enough messages to ONE recipient
.. in the interval between the first transmission and the first return
.. in a setting where *some* of the messages are rejected and *some*
are accepted
.. and the messages are so similar in character that the defective
ones can't be discerned from a headers-only response message
(including the Subject: line) ... (e.g. if I send a 400mb attachment
that's rejected as "too large" I betcha I could figure it out from an
error response and time stamp)
The more I think about this business of returning e-mails to the
_apparent_ sender, the more completely wrong it seems. It is an
anachronism and we should be considering putting an end to this
practice.
At 9:32 -0600 4/8/03, Vernon Schryver wrote:
] Is it _absolutely_ necessary to bounce back the entire message body,
] rather than just status and delivery data?
Yes, it is absolutely necessary that enough of the message be bounced
so that sender can know which message bounced.
] As a postmaster I can see message delivery details but not bodies and
] can diagnose just about anything.
Most mail senders care less about diagnosing the problem than knowing
which of their messages and to which addressee did not arrive.
] The idea of allowing a mail server
] to generate an entirely new message seems anachronistic at best,
] dangerous at worse. I do think most people keep an "outbox" today...
An "outbox" containing the 50 messages you've sent in the last 5 days
does not help deal with a bounce until you know which message bounced.
You need to know which message nees to be retransmitted or otherwise
handled. Even if the bounce contains all of the headers and you are
one in 10,000 who can read headers, you may not have enough information
to pick the original from your "outbox." Only if your MUA generates
Message-IDs that are preserved by your MSA and all subsequent MTAs in
the path might you reliably figure it out. The source of the bounce
cannot know if your MUA and MSA are sane. What can it do except
send most of the SMTP transaction log?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg