🚀 go-pugleaf

This discussion is getting absurdly out of hand.  No-one has
suggested using the "Return-Path" for replies anytime that
there's a From or Reply-To field in the header.

It doesn't seem entirely unreasonable to me to allow replies
to the Return-Path (or Sender) if there's no From in the message
(which clearly indicates that the sending mailer is broken).

But as reported, rfc822 forbids this.  In that case, I think
I'd just "fix" my mailer - if an incoming message arrives with
no From: field, then copy the Return-Path to a From header...

Same effect, and this isn't forbidden.  The right solution is
to fix the broken mailer - but that's someone else's broken
mailer, and getting others to fix their broken programmes isn't
always easy.

But, the rfc822 comments on where replies should be sent cannot
possibly be mandatory - its entirely irrational to try to forbid
to whom anyone sends mail (at least just on the basis of what's
in a header, ignoring political/financial problems).  A reply
is just a mail item, I can send it to anyone I like.  All that's
material here is for the headers to give some guidance on where
replies are intended to go, and for mailers to use this guidance
to establish the default recipients.

Normally, if someone sends me mail with both From & Sender headers
(indicating in the typical case that a secretary sent mail on
behalf of someone else) I would send a reply to the From header.
This would be a reply on some matter of substance in the mail.
On the other hand, if I don't like the way the mail is typed
(say I find some spelling error that offends me, or the layout
makes the mail hard to read on my terminal - wider than 80 cols)
then I think sending a "reply" to the Sender is entirely reasonable.

Yes, that's not a "reply" in some narrow sense of the word.
I intrepret the word more liberally though - any message
I send that is a response, of any kind, to mail I receive is
a reply (ie: if receiving the original mail was the stimulus
necessary to send my mail, then my mail is a reply).

Robert Elz			kre%munnari.oz@seismo.css.gov