ietf
[Top] [All Lists]

Re: All IETF posted email addresses MUST be real.

2010-01-22 11:31:47
I'm not sure why you are copying me on this; in the IETF I am a working group chair, a liaison to the Smart Grid effort, and one of the Trustees of the IETF Trust. If you are addressing me in any of those contexts, I would expect you to use v6ops-chairs(_at_)tools(_dot_)ietf(_dot_)org or copy my co-chair (and have the message be relevant to the IPv6 Operations Working Group), copy SmartPowerDir(_at_)ietf(_dot_)org (and have the message be relevant to the Smart Grid), or be sent to the chair of the Trustees and/or copy trust(_at_)ietf(_dot_)org(_dot_)

I debated replying to this for that reason, and because your email contains no specific call to action. Let me engage giving my view of this, and request your proposed call to action. I removed the IPR working group as this is not obviously on-topic for that list, and removed Russ as I believe he is on the IETF list.

The ramifications of this for the IETF are either minimal or massive; I suspect the former. If you are referring to the addresses that people use on blue sheets, it is the people who sign them that are responsible for the efficacy of their addresses. Email addresses are known to be temporary; if I go to work for another company, Cisco will invalidate fred(_at_)cisco(_dot_)com and several other addresses. Several of my older addresses (fbaker(_at_)vitalink(_dot_)com and fbaker(_at_)acc(_dot_)com for example) have been invalid for many years - I no longer work there and the company (and its domain name) no longer exist. If you are saying that the IETF is responsible to rev RFCs to maintain those addresses (eg, RFC 1381 should be revved to change fbaker(_at_)acc(_dot_)com to fred(_at_)cisco(_dot_)com or the IETF should maintain a way to contact authors/editors that transcends such issues), that has far-reaching consequences; at best I can suggest that the RFC Editor remove author/editor contact information (snail mail address, email address, and telephone number) from future RFCs as it is all ephemeral. If known-ephemeral information can be left that way, then this has minimal impact.

My understanding of the court decision, however, doesn't affect people that are working in the IETF context. Email addresses used in IETF mailing lists are verified in the course of signing up, and for lists @ietf.org, bouncing addresses are removed from the lists. In addition, moderation rules on IETF lists force manual processing of mail that has not been through that verification process - only registered recipients are permitted to post. Hence, addresses found on IETF lists should by that process be known to be working addresses. I seriously doubt that a mailing list operating in the IETF context (a "recipient" address) is covered under the CAN-SPAM act, which regards the address of the originator of an email.

What specifically are you calling for the IETF to do in response to this decision, and what classes of addresses does your proposal cover?

On Jan 21, 2010, at 7:26 PM, tglassey wrote:

So Fred and Russ - we talked about this once before - Now there is a court ruling on using fraudulent email addresses in any public process. So this also means that all IETF posted email addresses MUST be real and functional so responses can be sent to those parties directly according to the 9th Circuit's interpretation...

Bummer that eh? Think what this means to the IETF and its policies.


Todd
--------------------------------------------------------

Jan/12/10| WHOIS Privacy Considered “Material Falsification” A recent decision by the Court of Appeals for the 9th Circuit By Ryan Sadler, Legal Team

A recent decision by the Court of Appeals for the 9th Circuit has determined that using WHOIS privacy on domains may be considered “material falsification” under federal law. The defendants in US v. Kilbride (9th Cir., 2009) were convicted under the CAN-SPAM Act in a case that involved criminal charges of intentional email spamming. Enacted by the US Congress in 2003, the CAN-SPAM Act prohibits false or misleading transmission information, deceptive headers, and requires email solicitations to give an easy opt-out method and be labeled as an advertisement, including the senders physical post address. Commercial emails that use false or misleading headers, or violate other CAN-SPAM provisions, such as falsified registration information, are subject to fines of up to $11,000 for each unsolicited email sent.

The CAN-SPAM act states that “registration information is materially falsified if it is altered or concealed in a manner that would impair the ability of a recipient of the message…to identify, locate, or respond to a person who initiated the electronic mail message…” The defendants argued that since the terms “impair”, “materially falsify” and “conceal” are not defined in the statute they should be considered unconstitutionally vague. The court responded to the defendants’ assertion by clarifying that “when Congress does not define a term in a statute, we construe that term according to its ordinary, contemporary, common meaning.” The court then made it clear in their ruling that the defendants’ use of private WHOIS information in this case materially falsified the registration information. The court declared that “It should have been clear to the defendants that intentionally falsifying the identity of the contact person and phone number [through WHOIS privacy] for the actual registrant information constitutes intentionally decreasing the ability of a recipient to locate and contact the actual registrant, regardless of whether a recipient may still be left some avenue to do so. We therefore conclude defendants had notice that their conduct violated the CAN-SPAM act.”

Although the ruling does not make use of WHOIS privacy illegal, it does serve as a clear message from the court that coupling the use of privacy services with intentional spamming will likely result in a violation of the CAN-SPAM act. This is an important decision that members of the domain community should refer to prior to utilizing a privacy shield.

-----------------------------------------------------------

http://www.ipinc.net/IPv4.GIF

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf