----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
To: "ietf-822" <ietf-822(_at_)imc(_dot_)org>
Sent: Monday, June 06, 2005 11:26 PM
Subject: Re: Understanding response protocols
550 Return Path not verifiable. (in reply to RCPT TO command)
Please fix your buggy server.
Oh boy! There goes your modus operandi again! Here we go again with the 2
year old "Brucy" degrading every conversation ANYWAY or ANYWHERE when he
don't get his way! Brucy, are you capable of having an form of
non-confrontable conversion? Nah, that is impossible!
Bruce, for the 3rd time, you were twitted on our system. You can't send to
our system using EOLS.COM domain. The same with your side-kick. We use a
delay verification system hence why it checking is done at RCPT TO until it
is known you are sending to a local destination address. Elusive or not.
Everyone gets the same response depending on the TMS <tm> (Transaction
Management and Security) plug-in. The local server side logs provides the
reason for the rejected transaction.
I did this the last time we had this Reply-To-List/Reply-To debate to prove
the point that I don't what you to REPLY directly to me but to the LIST
instead. Pretty much for the same reason you now finally saw the light and
are forcing a natural reply to the list by defining Reply-To: to the list
instead of the AUTHOR - YOU!
1. mailing lists have been around since well before RFC 724 (1977).
And what kind of environment did we have in 1997?
ONLINE systems? Since when where you able to set a Reply-To in MUA in 1977?
Did you have an MUA on your VT100? Your WISE terminal, your Tekronik Raster
graphics terminal?
And if you were able to do it with your Pet PC computer, using a tape based
offline MUA written in ADA, FORTRAN or god-forbid APL, the server-side
list mail/server still has control over how the make the more common system
can easily respond using the standard BACK to the list REPLY BUTTON address.
Look, no system or network had a concept that converged or merged ONLINE and
OFFLINE considerations as a single concept where you have:
FROM:
DATE:
TO:
SUBJECT:
REPLY-TO:
CC:
Nearly all systems had only 3 options:
REPLY TO SENDER - REPLY-TO: | FROM:
REPLY TO ALL : REPLY-TO | TO | CC
FORWARD: blank
and this was either for online or offline systems. Only more advance systems
had concepts where they might augment with
REPLY TO ORIGINAL AUTHOR
REPLY TO ORIGINAL RECEIPT
and MORE important as part of the security for a online system, the USER had
absolutely NO control over it would reply to in the conference system. The
system handle it.
This began to change with OFFLINE, store and forward systems. However, the
better mail server still did security integrity checks with uploaded offline
mail to make sure the offline behavior was consistent with the online
behavior. If the mail server did not check the integrity of the uploaded
message, than it was a POOR server and had a hole into the mail system.
Never mind the fact that mail delivery and reliability was at stake.
Bruce, you are out of your league here. I can spin you a thousand times with
the design issues that are involved here.
Note
that RFC 724 also defines the semantics of the Reply-To field as an
author-supplied suggestion for responses and specifically mentions
"text-message teleconferencing", i.e. mailing lists.
Right, and to clearly point out what it says:
| More interesting
| is a case such as text-message teleconferencing in which an
| automatic distribution facility is provided and a user
| submitting an "entry" for distribution only needs to send
| their message to the mailbox(es) indicated in the "Reply-
| to:" field.
Which suggest that in a group environment, the natural reply is to go to the
suggested reply-to field.
However, once again, it was designed around online systems and it is the
online system that ulitimates defines the distribution. The END USER has
ABSOLUTELY
no control over online system mail policies.
What you are suggesting, as I said in another forum, that a OFFLINE MUA has
more control over how mail is transported over a system. Sorry, it doesn't
buddy. An offline system will not define how a mail server policy will
behave.
What you suggesting that a USER has control over his FROM field in a online
system. He typically doesn't.
And again, we are taking about the ergonomics of the natural reply process
which I am getting sick and tired of explaining to you over and over again.
Ironically, you just did it yourself. You purposely set the reply-to:
address to the IETF-2822 mailing list address because you know it for
yourself that is how the natural behavior for ALL MUAs to behind. It was
your way to make sure the maximum set of users will reply to the right
address when responding to your mail without extra confusing field editing
or using a "Reply to All" concept to get the list address.
If you did not do this, then a NATURAL REPLY will go back the to FROM:
address which is NOT what the user wanted in 99.99% of the cases. His
intentions is to reply to the list, not to you. That is why you set up your
MUA folder to force the Reply-TO: to the list address.
2. "alias" and "mailing list" are different. See RFC 2821 section 3.5.1.
char *ReplyToSender()
{
char *to_address = reply_to_address;
if (to_address empty) to_address = from_address;
No and no. Reply-To != Sender. From != Sender.
Clearly, you have no credentials in mail software designs. Absolutely no
brain for the matter. You are a paper pusher, doc pusher, technie end-user.
No more, no less and when you can't hack it, you resort to put downs and
ad-nausem facts that are clearly not even in question. Hey, don't get me
wrong. We typically people like you to dot all the i's and cross the t's.
But you really don't have no right to be involve in this design discussion.
It is beyond you at this point. When a draft is written, that you can join
the conversation again.
How about those adam apples?
People, write your proposal to identify a LIST ADDRESS and present it to
all the MUA, LIST SERVER authors. We know better than Bruce whether its
needed or not.
Rest assured it will be considered very strongely if only for the key reason
that we do want to make sure we retain the Reply-To: address in a LIST
expanded system.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com