[rfc-i] Pre-IETF RFCs to Historic (not really proposing)
touch at isi.edu
Sun Sep 18 16:09:36 PDT 2011
On Sep 18, 2011, at 3:29 PM, Dave CROCKER wrote:
> 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.
My email in all my RFCs is touch at isi.edu
Let's say there's a new address: rfc1810 at ietf.org -> touch at isi.edu
The highest RFC today is in the 6000's. Let's say I write an RFC in the 7000's - 7010, e.g.
1) a spammer now knows the future email address of all RFC authors without doing the work of scraping the RFC text
Let's say I change my email to touch at newaddress.example.com
If the IETF does nothing, then there's now new exposure to spam.
If the IETF updates rfc1810 at ietf.org to point to touch at newaddress.example.com, then they have a way to reach me again.
Basically, if it's a forwarding address then:
a) it's easier to spam if it's computably guessable than if it's scraped
b) it's easier to spam if it tracks my address when I don't want it to
The IETF configures email lists to "hide" email addresses in ways that a scrape could get (touch at isi.edu, vs. touch at isi.edu). If that's valuable to subscribers, as is hiding the full list of subscribers, then clearly not making these aliases available is in the same spirit.
> 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 address.
That was what was proposed, and that's the part I am concerned about.
A simple address that serves as a convenience for information that's already in the RFC is of much less concern.
>>> 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…
The current doc asks for contact info explicitly; I provided it explicitly.
Providing an alias to that may be OK, but providing an alias that changes to track my current address is fairly clearly in direct opposition to everything provided explicitly. Do we really need to test that in a court?
More information about the rfc-interest