FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity.
2004-11-19 23:52:41
My take on the FTC Email Authentication Summit :
0) Lies
1)Yahoo & DK.
2)GoDaddy DNS & SPF & CSV.
3)Dean & FUSSP.
4)Testing
5)EFF, Anonymity.
+++++++++++
0)Some lies and misleading statements from Microsoft's Harry Katz (& Ryan):
He said that in order to validate an email, per SenderID/CallerID/SPF,
you need to <Do a query of the DNS>. We all should know by now that it
could be a hundred DNS queries, and is not likely to be one query.
He said that no changes are required to MUAs. Well, sure they aren't
uh, 'required', but they're 'needed' to address the phishing problem
with SenderID. I better buy a new version of Outlook, huh?
He said that SenderID protects the address most likely to be seen.
Well, no, some spammers have already adapted and use, e.g. the Pretty
Name or Sender: to make the recipient see what the addresss they want
them to see in their MUA. SPF and SenderID *DO NOT PROTECT* the
"From:"! (Equifax (which represents the banks of the phished) confirmed
this.) (Given that Bill Gates believes that SenderID protects the
"From:" line too, poor Harry is a bit stuck.)
He said, roughly, "I _believe_ SenderID is as efficient and as easy to
deploy as CSV." Some folks _believe_ the earth is flat. It's not about
_belief_, but technical reality, and M$ is dodging the tough questions.
I heard no argument to back that statement, and gobs of evidence
indicating that it's false.
Despite strong evidence to the contrary, he states that he _believes_
not that CSV would provide greater benefit for less cost, but rather the
reverse, but no explanation - clearly we should have _faith_ in Microsoft.
I found it chilling that right after around a dozen exploitable security
holes in his proposal were pointed out to Harry, he proceeded to
encourage everyone to adopt it.
My main question for Microsoft's David Kaefer, Esq? : Why haven't you
adopted a "If you don't sue us, we won't sue you" license, like Cisco's,
as Scott Bradner said? It provides everything you said you needed. It
just doesn't trip up Free Software, which I conclude (mostly for lack of
other plausible explanation) must be the real reason for the current
license.
Basically, I heard vague, impressive-sounding statements to impress the
non-technical. I was disappointed to hear several false statements that
have already been discredited made again. Are the transcrips available
yet? It'll be good to make these exact quotes, not just paraphrases.)
=-=-=-=
1)Did the Yahoo folks at the FTC conference say that they would be
signing all outbound mail by now, and would be checking incoming mail soon?
Mail I sent from my Yahoo (premium) account on Wednesday isn't signed.
Is the replay problem solved? Until it is, I see no point in deploying
DK or IMM, since they won't work long term.
=-=-=-=
2)GoDaddy DNS & SPF & CSV
FYI (Go Jason & Mike, Doug & Bob!) :
Dear Mr. Elvey,
Thank you for writing. We appreciate your having taken the time to contact
us on this matter. This is a good suggestion and we will forward it to our
development department for review and consideration. Please let us know if
we can be of further assistance.
Kindest Regards,
president godaddy com
Douglas Preston Jr.
Office of the President
GODADDY.COM
14455 N. Hayden Road, Suite #226
Scottsdale, AZ 85260
480-505-8828 - phone
480-505-8844 - fax
-----Original Message-----
From: Matthew Elvey [mailto:matthew elvey ]
Sent: Wednesday, November 17, 2004 3:43 PM
To: president godaddy
Subject: GoDaddy and the FTC Email Authentication Summit.
Hi. I attended the FTC Email Authentication Summit, where I heard and
spoke with Mike Chadwick.
Mike suggested I email you about an issue with Email Authentication and
Go Daddy-registered domains.
Currently, even when 'Total DNS Control' is enabled, one cannot set up
records to comply with the leading
Email Authentication proposals - SPF and CSV. Can you please remedy
this ASAP? Mike said
"Godaddy believes that customers need the ability to protect their
domains easily"
so please make this possible by making it possible to set up SPF and CSV
records (i.e. TXT, SRV and PTR records).
Thanks in advance! And let me know if you have any questions about
what's needed or why. I'm happy to clarify.
--
Matthew
=-=-=-=-=-=
3)Dean & FUSSP.
Dean Anderson of av8 seems best largely ignored,
given odd evidence suggesting his views are that DNSBLs are terribly,
horribly, drastically, irretreivably bad and other ranting:
http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-May/006714.html
(and
http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-June/006933.html
and the results of #whois 130.105.36.66 and
http://moensted.dk/spam/messages/20020716-dean+av8.com.txt ); forgive me
if I'm skeptical about his statements.
I am confident an implemented long term solution that will keep inboxes
functional and nearly spam-free is in the not-so-distant future. It's
not like a perpetual motion machine: un-inventable. Plus, Information
Theory is cool and fun. I've found it useful for pointing me in the
right direction for handling this plague.
=-=-=-=-=-=-=
4)Testing in general, and CSV Testing at AOL
I was mostly pleased to see Carl announce that AOL will be testing CSV
based on my "Make CSV backwards compatible with legacy SPF records?"
ideas. Pleased to see it growing roots, but wishing this testing had
been preceeded by better dry runs. (I'm not surprised AOL has been
unable to implement SPF inbound, and that AOL is finding forwarders not
using SRS to be a major barrier to using SPF to identify spam.)
The call (which I heard expressed a few times at the FTC) for lots of
testing annoys/worries the heck out of me. Here's why:
1)What has failed to happen so far is sufficient bench testing. Why
test something in the field when a simple lab-bench test suggests it
won't work? Let's consider how silly our behaviour looks when compared
to the way cryptography schemes are developed. A crypto scheme is
generally announced, and actively discussed in the community. Attacks
are theorized and defenses are presented by the scheme's proponents, in
extensive open discussion, long before field tests are used to see if it
works. On MARID, we've seen security flaws poo-pooed. Doug has
described, in detail, some extremely damning attack vectors on SenderID,
essentially arguing that it'll be a disaster (e.g. on-list and
http://www.csvmail.org/email-authentication-summit-comments-P044411.pdf
). I haven't seen any response. Given how often he describes them,
this omission is all the more glaring. I'm not suggesting we not proceed
with real world testing, I just wish there was cooperation on from
Microsoft with bench testing. Microsoft performs a disservice by not
responding.
2)Also, I worry about conclusions based on tests that are not
sufficiently realistic to provide more accurate guidance than bench
tests do. Given that SPF requires any domain used in HELO have a valid
SPF record that authorizes that use, I expect at least one positive
metric from the testing. However, I fear a real world test that doesn't
involve good and bad reputations having real consequences; I fear
decisions made based on such unrealistic tests. (If AOL's test of CSV
will impact SCOMP-like reputations, I'll worry much less!)
PS Carl, please contact me for licensing terms. </joke>
=-=-=-=-=-=-=
5)EFF, Anonymity.
I asked the EFF's Policy Analyst Annalee Newitz: "You have essentially
said Domain Authentication is unaceptable. The EFF's position on spam
is that all wanted mail must be delivered to the users eyeballs. I can
think of no useful antispam solution in use today or being considered
here that guarantees that. Please identify and discuss at leat one."
She said that the EFF supports the use of tools like SpamAssassin if
they leave the user in control, and that she plans to publish a paper
clarifying/changing the EFF's position soon. I hope so! (The rationale
behind my question is that since no filter is perfect (100% FP-free),
therefore no filter is acceptable to the EFF.) Ooh! Looks like this is
it: http://eff.org/wp/?f=SpamCollateralDamage.html :) but,
http://eff.org/Spam_cybersquatting_abuse/Spam/position_on_junk_email.php
is still wrong; an update is in order, IMO.
OTOH, this rather silly argument put forth regarding anonymity: <If we
eliminate email anonymity, it's not a big deal because other venues
provide it, such as websites , wikis and blogs.> It's silly because
when these other venues aren't protected from junk messages, they become
the next target. *So we need a solution that is easily extendable to
protect other media venues such as these, and doesn't eliminate email
anonymity. It would be cool to see the EFF set up a reputation service
(CSV,SPF,CID-supporting) that listed MTAs/domains run by political
organizations, and/or a CAPTCHA-protected anonymous mailing facility
that kept no logs.* I'd certainly use the former and probably use the
latter.
=-=-=-=-=-=-=
People Issues - great presentation; I fervently hope more of us read it
closely and comply.
=-=-=-=-=-=-=
Most impressive:
The folks from the FTC running the conference. They get it. I was
pleasantly surprised.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity.,
Matthew Elvey <=
- Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity., Alan DeKok
- Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity., Dave Crocker
- Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity., Alan DeKok
- Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity., Dave Crocker
- Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity., Alan DeKok
- A new SMTP "3821" [Re: FTC stuff...........], Hector Santos
- Re: A new SMTP "3821" [Re: FTC stuff...........], Andrew Newton
- Re: A new SMTP "3821" [Re: FTC stuff...........], David Woodhouse
- Re: A new SMTP "3821" [Re: FTC stuff...........], Alan DeKok
- Re: A new SMTP "3821" [Re: FTC stuff...........], william(at)elan.net
|
|
|