At 04:17 PM 03/06/2003 -0800, Fred Baker wrote:
Look through the header lines on this email, and tell me who is the sender
and who is the recipient? My system (my PC) very likely never spoke with
your PC. Rather, it traversed a number of SMTP sessions, going from relay
to relay, such as (copied out of an email I sent earlier in the week and
received back on this list):
My PC -> mira-sjc5-b.cisco.com
-> sj-core-2.cisco.com
-> ietf.org
-> www1.ietf.org
-> proxy1.cisco.com
-> sj-msg-av-3.cisco.com
-> sj-core-2.cisco.com
-> mira-sjc5-b.cisco.com
and finally a POP session to my PC.
The Received lines tell you nothing directly about who the sender and who
is the recipient.
In the case of a mailing list, there are two transactions:
1. First transaction -
a. The sender is the person submitting a message to the mailing list.
b. The recipient is the mailing list system.
2. Second transaction -
a. The sender is the mailing list system.
b. Each person subscribed is a recipient.
The first transaction requires the consent (express, inferred or implied)
of the operator of the mailing list.
The second transaction requires the consent of each subscriber - this
consent was given by means of the subscription request.
The fact that a number of systems were involved in the middle has no
bearing on the matter.
So I don't think either end user talks with the other, and their direct
agents (laptops) don't.
This is only a problem if you insist on using some enhancement to SMTP to
express consent. Since consent is something communicated by the recipient
to the sender, for the reasons including those you indicate, enhancing SMTP
is probably not a good way of expressing consent, at least on an individual
level. Hence the BMTP and BMPP protocols designed by people from CAUCE and
CAUBE.AU(*). Those protocols were designed specifically to deal with consent.
(*) To these you would add the SMTP banner specification if you were
looking to review all of the protocol proposals made by CAUCE groups, but
that specification only deals with expressing a refusal of consent at the
domain level.
--
Troy Rollo Chairmain, CAUBE.AU
asrg(_at_)troy(_dot_)rollo(_dot_)name Executive Director, iCAUCE
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg