[rfc-i] Pre-IETF RFCs to Historic (not really proposing)

Dave CROCKER dhc at dcrocker.net
Sun Sep 18 15:29:28 PDT 2011

On 9/18/2011 2:08 PM, Joe Touch wrote:
> On Sep 18, 2011, at 1:20 PM, Dave CROCKER wrote:
>> Although the industry has quite a bit of variance, I've never seen any
>> credible definitions that quite match yours.  The usual concern is for
>> unsolicited /bulk/ mail, rather than the assignment of a 'role' address to
>> facilitate direct work initiated by the addressee.
> You're creating an alias to my email address and having it track me. That is
> enabling spam.

Having /any/ address that is visible "enables" spam.  A role-based address is no 
more, nor less, subject to spam.  That is, the mere fact of an alias is irrelevant.

Since you believe otherwise, please explain this, in technical terms that relate 
to the real world of spam -- the stuff generated by folk who flood 90-98 percent 
of today's email traffic flow across the open Internet.

You cite 'tracking' so presumably that's what you intend as the relevant factor, 
but of course there's the small matter that the role address doesn't actually 
/do/ the tracking.

Tracking is done by whatever process updates the alias.

Whether you can foil that process depends upon the operational policies of the 
updating organization. In the case of the IETF and/or RFC-Editor, it seems more 
than a little likely that they would be responsive to an individual's desire. 
As of now, I believe they are not doing updating automatically (whatever that 
means) nor has the basis for updating been discussed in the proposal for a role 

> Oh, if you don't think so, then you should start with a few other "fixes" to
> make it easier for the community dialogue (the IETF's goal, as you note):
> - make the list of subscribers to all IETF email lists public - make the

How is that relevant to this thread?does

> archives show posters email addresses explicitly isn't the "joe at
> example.net" with a link to "joe at domain.hidden" working against community
> dialogue?


>> Basically, you have the most restrictive view of the social contract for
>> participation in the IETF that I've seen in quite awhile.
> The IETF already goes to lengths to protect user email addresses from spam as
> above. Setting up tracking accounts that get around all that is a bad idea.

Well, the intend might be to provide protection, but it doesn't work.  The 
reality is that addresses of participants in IETF lists are fully public. 
Believe it or not, serious spam email scrapers know about the " at " conventions.

{ and just for historical note, for those with less that 30 years of Internet 
experience, " at " used to be as valid as "@".[1] }

>> For reference, my own view is that the social contract should be to make it
>> a condition of document submission that one is willing to be contacted
>> about the document and that includes through role-based addresses
>> affiliated with the document, rather than requiring respondents to guess or
>> track down the correct address.
> The author provides contact info in the doc. The author can use either a
> specific email or a persistent email address as they chose at that time.

Whatever "persistent" means in the real world of email addresses...

(There's also the small matter of changing one's mind later, as sometimes 
happens in the real world.  That's currently prevented.)

> Setting up a "service" to get around the explicit indication of the author is
> a violation of the social contract that you've already established.

I suspect the current contract is silent on the matter...


[1]  RFC 733


   Dave Crocker
   Brandenburg InternetWorking

More information about the rfc-interest mailing list