Right. so Header != Body
If senders could just learn (I believe they can) to revisit the
outbox and examine _that_ copy, then there is no reason whatever to
clone message bodies and send them to FROM: addresses.
I think the idea of a bounce that contains the original message body
has been the core problem and a vector for spammers... and could be
solved by mandating a return-to-sender of full status data less any
of the message body.
This would remedy a security/privacy hole as well w/r/t misdirected
returns, admins and unintentional storage of transient stuff.*
- jim
-----
* The notorious follow-on topic/extension "there is no expectation of
privacy in e-mail" is hereby decreed off-topic for this thread.
Please don't go there or I'll have to call someone.
At 7:46 -0700 4/8/03, Chuq Von Rospach wrote:
No, but I think it's important to return a full header at the
minimum. It depends on who you think your audience for the bounce
is. end users tend to want the whole thing so in case of a typo on
sending they can get the message back adn send it again. programs
that process bounces need enough info to process them properly.
Some folks return messages chopped off at some size, a useful
compromise except it truncates MIME messages, which sometimes makes
life interesting.
If I have a DSN that tells me what address it was originally sent
to, I'm happy. If the DSN went through two sites that rewrote the
addresses and now has no relevance to what it started out as, I need
the full header to try to reconstruct what was broken along the way.
If the header gets partially stripped (only minimal headers) I need
the body to try to get around that. The more you muck with the
message, the more message I need to avoid your mucking... (grin)
On Tuesday, April 8, 2003, at 06:15 AM, Jim Youll wrote:
Is it _absolutely_ necessary to bounce back the entire message
body, rather than just status and delivery data?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg