At 8:39 AM -0400 9/25/03, eric(_at_)infobro(_dot_)com wrote:
> Looking over the (as-yet-undefined) definitions I see that there is a
1.3.31 for "Sender" but I don't see anything that would distinguish
between the originator of the message and the organization handling the
delivery. This is important because the two roles may be separate, in
which case the best practices for each will be somewhat different.
Hmm, that's a good point. I think we should make it clear that the
"Sender" and "Receiver" of the email refer to the human beings or
software agents which originally sent the email, not the MUA or MTA that
was used. If that is true then what does "Message Originator" refer to?
In general, we need to look over the definitions and decide which are
relevant and which are not, and make clear the distinctions between
different aspects. We might also need another section in this document
which outlines the mail delivery model and plugs in all of the
definitions, so the reader of the document can readily see the
definitions "in action".
EW> There is a model presented and the points Kee raises are valid. I feel
that the distinctions that are raised may be relevant to a discussion of
delivery methods (these types of disctions were revised in a later draft,
which I will forward now) and origination agent (MUA) and "Sender" are
presented as distinct definitions.
I may just be misunderstanding you, but I'm still not sure I've made the point.
The majority of non-spam bulk mail on the internet is not being sent
by the entity that composed the mail and owns the list. It's being
sent by third-party companies on their behalf. So in a typical
situation you have a company that shows up with a database of email
addresses, they sign up with a bulk sender, and the sender gives them
an interface to compose their messages. The bulk sender usually
makes an attempt to clean the user's list and make some determination
of whether it's a "valid" list. But at some point they send out the
email on behalf of the entity that composed the message.
Of course it can be far more complicated than that, since there will
be automated messages (subscription notifications, replies, support
email, commerce notifications) that might go directly from the bulk
mailer without the interaction of the list owner.
There is also a tremendous amount of behind-the-scenes activity going
on here that I think most people have no idea about. Legit bulk
senders expend considerable effort working with major ISPs to make
sure their email doesn't get blocked. ISPs have trust levels
associated with different IP addresses. Bulk senders use separate IP
addresses for known good customers and new customers....
Anyway. One of the major issues in looking at consent is that there
is a gap in the verification process. When a customer hands a list
to a bulk sender there is no way currently to verify that the
customer has in fact followed any BCP for consent.
I believe the document needs to call out each of those roles
separately, and any system needs to consider the proper actions for
situations in which the list owner and list sender are separate roles.
Also, another item that may want to go in the definition list is
e-pending, in which a company takes a list of off-line addresses and
figures out (perhaps) what the appropriate email address is for those
addresses. Needless to say this throws an interesting monkey-wrench
into the "can send email if you have a prior business relationship"
model.
EDW> This as well was changed in a later draft. Unfortunately, these
subsequent drafts were being discussed off-list. The document which I
forward may be a closer fit to the ideals of the list at present.
BTW, more people are needed to work on this, can the volunteers step
forward?
Those two statements are related. I think if you want volunteers you
need to keep the discussion on list. It may make things more
difficult with side-tracks and interruptions, however it will
generate more interest and participation. (How much it will help
find people to write things up though, I don't know. Certainly my
participation on this list goes in waves, depending on my
workload--that's not what you'd want from a document owner.)
Also you have another fundamental problem. You've backed off to a
level of abstraction where agreement is possible--but that also means
it's far enough away from the problem that people don't see its
relevance. My personal feeling is that the most valuable thing that
could come out of this group is a strong statement of consent, with a
particular goal of defeating the U.S. Congress', and DMA's attempt to
make opt-out the standard model. We all know that won't work. But a
united front from the internet groups behind a common definition of
what levels of consent must be required would help. Along with that
model, could come a set of BCPs for senders, receivers, spam filters
and ISPs. There are other groups working on portions of that (see
http://www.isipp.org/standards.html, a document that came out of the
Summit I and Summit II conferences that brought major senders and
receivers together to talk about email deliverability). I think that
ASRG (in it's newer, mellower form) could contribute to that process.
--
Kee Hinckley
http://www.messagefire.com/ Next Generation Spam Defense
http://commons.somewhere.com/buzz/ Writings on Technology and Society
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg