[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] 3. Requirements Document

At 8:39 AM -0400 9/25/03, eric@infobro.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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg