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@xxxxxxxxxxxxxx
or copy my co-chair (and have the message be relevant to the IPv6
Operations Working Group), copy SmartPowerDir@xxxxxxxx (and have the
message be relevant to the Smart Grid), or be sent to the chair of the
Trustees and/or copy trust@xxxxxxxxx
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@xxxxxxxxx and several other addresses. Several of my
older addresses (fbaker@xxxxxxxxxxxx and fbaker@xxxxxxx 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@xxxxxxx to fred@xxxxxxxxx
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
