Subject: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity.

From: Matthew Elvey <[email-masked]>
Date: Sat, 20 Nov 2004 01:52:37 -0500

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.

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 20 Nov 2004 09:33:05 -0500

Matthew Elvey <[email-masked]> wrote:
> works.

  The key here is "open discussion".  The SMTP/anti-spam field
involves so many strongly emotional positions that open discussion is
rare.
>  On MARID, we've seen security flaws poo-pooed.

  In cryptographic circles, the people who develop encryption schemes
accept the fact that their schemes are flawed, when provided with
proof.  The people who attack encryption schemes accept the fact that
their attacks are flawed, when provided with proof.  The goal of both
parties is to provide provable security.

  The failure of SMTP to protect from forgery, malicious bounces,
etc. is a failure of the security model of SMTP.  Until that's
analysed and fixed, all of the proposed schemes are band-aids.  And
even if they're all fixed, it will still be possible for a million
random people on the net to send you email, because that's a goal of
email.  And those people can all choose to send you spam.

  Spam will never go away.  But we can make it easier to track, and
easier to hold people accountable.

  Alan DeKok.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Nov 2004 07:59:39 -0800

On Sat, 20 Nov 2004 09:33:05 -0500, Alan DeKok wrote:
>    The key here is "open discussion"...

Some major keys to open discussion is that people avoid ad hominem attacks -- for example, they do not call people liars -- and they avoid hyperbole.  For example:

>  etc. is a failure of the security model of SMTP. 

The security model of SMTP is the same as the security model for sending paper letters and for making phone calls.

To "fail" requires that there be a goal that was not attained.  That's not the case here.  The case here is that real threats changed after 25 years of operation and we need to adjust to them.

When crime goes up because a small town becomes a big city, and we have to add locks to our doors, we do not say that the security model that used to work "failed".  We say that it changed.

The key to open discussion is that people say things thoughtfully and with an attempt to be accurate and precise.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
www.brandenburg.com

---

From: John Levine <[email-masked]>
Date: 20 Nov 2004 19:04:43 -0000

>0)Some lies and misleading statements from Microsoft's Harry Katz (& Ryan):

The Microsoft people came to make political statements, not technical
ones.  It was dismayingly clear that Harry et al have decided that
Sender ID's technical failures don't matter.  I wouldn't call it
lying, perhaps corporately enhanced myopia.

>signing all outbound mail by now, and would be checking incoming mail soon?

I just checked and they're signing my free Yahoo mail.

>DK or IMM, since they won't work long term.

What replay problem?  The fact that a recipient MTA can forward a
message and not break the signature is a feature, not a bug.  If you
want to avoid accepting old stale mail, you can always check the
header date which DK and IIM should be signing.  The point of DK or
IIM is to say that the putative author really is the author of a
message, and if a recipient remails it, that doesn't change.  It does
put the onus on message authors to avoid sending mail to recipients
who will misuse it, but that's nothing new.

The alternative is to take a big gulp of SPF kool-aid and decide that
mail forwarding has, after 20 years, stopped being part of the way
that SMTP mail works.  I hope we don't want to go there.  If we want
SPF, we all know where to find it.

>5)EFF, Anonymity.

At last year's FTC spam forum Cindy Cohn, who is otherwise a very
smart person, didn't have a clue about e-mail, and it was clear last
week that the EFF hasn't learned anything in the meantime.  It was
pretty telling that Annalee said she sorts through 2000 spams a day by
hand and apparently thinks that's a useful way to spend her time.

>The folks from the FTC running the conference.  They get it.  I was

Yes indeed.  Too bad the Congress hasn't given them better tools to
work with.

-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
[email-masked], Mayor, http://johnlevine.com, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 20 Nov 2004 17:17:10 -0500

What is so surprising to me is that its done all right in the open. But then
again, that's been the modus operandi of the new Marketing/Campaigning era,
"just fib enough times, and people will eventually believe you."

It is as Gates said, "a strategy competitive advantage" to have the "spam
solution." The key thing here is that Microsoft wants the title for "solving
the problem."

Of course, open source is part of it. Just read Ballmer's Asian trip
statement about the 288 patent violations committed Linux and open source!

http://www.pcpro.co.uk/news/66121/ballmers-asian-ip-warning-set-to-backfire.
html

Coupled with the fact that FireFox just got TV National Headlines yesterday
and how its growth is troubling Microsoft,  this IP soap opera is just the
beginning.

http://msnbc.msn.com/id/6462569/

I bet Bill doesn't like MSNBC talking about it. <g>

---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com

----- Original Message -----
From: "Matthew Elvey" <[email-masked]>
To: "MXCOMP" <[email-masked]>
Sent: Saturday, November 20, 2004 1:52 AM
Subject: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean &
FUSSP. 4)Testing 5)EFF, Anonymity.

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 20 Nov 2004 17:19:11 -0500

----- Original Message -----
From: "Alan DeKok" <[email-masked]>
To: "MXCOMP" <[email-masked]>
Sent: Saturday, November 20, 2004 9:33 AM
Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV.
3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity.

> analysed and fixed, all of the proposed schemes are band-aids.

Hear! Hear!

So when do we start cleaning up SMTP?  <g>

---
Hector Santos

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 20 Nov 2004 17:38:56 -0500

Dave Crocker <[email-masked]> wrote:
> Some major keys to open discussion is that people avoid ad hominem
> attacks -- for example, they do not call people liars -- and they
> avoid hyperbole.  For example:

  To quote:

 http://www1.ietf.org/mail-archive/web/asrg/current/msg10826.html
 > you want to change the nature of the infrastructure. you want to
 > redefine established terminology.

 http://www1.ietf.org/mail-archive/web/asrg/current/msg10855.html
 > In professional fora, it is entirely inappropriate to make assertions
 > about other people's desires, capabilities, and the like.

  Both of the above quotes are from the same person.  I have little
reason to defend myself from accusations made by someone who is guilty
of exactly the same behavior he is accusing others of.

  That kind of double standard in this area has been a considerable
source of frustration to many people I've talked with off-line.  Most
of them, however, are unwilling to publicly rock the boat by saying
things like "SMTP is imperfect", for fear of getting attacked.

> The security model of SMTP is the same as the security model for
> sending paper letters and for making phone calls.

  For one, you haven't explain why.  Statements of belief aren't
statements of fact.  At the minimum, SMTP is electronic while paper
mail is not, so from that information alone, the security models MUST
be different.

  For two, phone calls don't have "malicious bounces", so I'm confused
why the security models for SMTP and telephones would be the same.

  For three, my statement was talking about failures of a model, not
about comparisons with other models. Claiming that SMTP has the same
security model as something else is nice, but not really relevant to
the issue thar the security model of SMTP has had demonstratable
failures.

> To "fail" requires that there be a goal that was not attained.
> That's not the case here.  The case here is that real threats changed
> after 25 years of operation and we need to adjust to them.

  i.e. the goal of SMTP has expanded: to protect from new threats,
which were previously minimal, or unknown.

  SMTP as it was designed 10 years ago has failed to reach these new
goals.  This isn't surprising.  As you point out, it was never
intended to reach those goals.  That doesn't change the fact that the
security model of SMTP has failed, and continues to fail, to protect
from attacks which it was never intended to deal with.

  This shouldn't be news.  It shouldn't be a sore point, either.

  The important thing now is to decide WHY the model failed, and HOW
it failed.  Without that information, it will be impossible to fix it.

> The key to open discussion is that people say things thoughtfully
> and with an attempt to be accurate and precise.

  That's half the battle.  The other half is that people hearing those
statements listen to them, and respond thoughtfully to their content.

  Alan DeKok.

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 20 Nov 2004 17:37:59 -0500

And with all due respect for your credentials and expertise, I have a
problem grasping your philosophy and analogies.  Phone and Snail Mail
actually has better security than SMTP.   POTS enjoys "real" caller-id
technology and snail mail atleast as a "permit" system and "official"
delivery entity in place.

I guess that makes me 'stupid' in your eyes, I guess that makes me
"un-informed" in your view,  I guess that makes me well, not worth hearing
out.  That's how I see it played out in the IETF "arena."

Look, it is a SMTP problem and the SOLUTION is at SMTP.   Either you change
it, clean it up or you don't.  Can't expect chaos and hence, a propensity to
stability to occur unless the target audience is forced to adapt as well.

I apologize for my tone if viewed the wrong way, but this attitude has been
what's keep the required R&D for SMTP "3821" to materialized.  Where the
hell is John Klensin?  That is has been the biggest disappointment to me as
an "greenie" (not to be construed as inexperience) in IETF.   The #1 person
that should be INVOLVED in any SMTP related discussion hasn't set foot in
the WG - then and now.  He gave me his reasons privately.

Now explained that?

I even suggested that he pass the torch to someone who can sincerely
champion the next era of Email and SMTP development.  Obviously, its a
struggle for some in IETF let go.

Sorry

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Alan DeKok" <[email-masked]>; "MXCOMP" <[email-masked]>
Sent: Saturday, November 20, 2004 10:59 AM
Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV.

Some major keys to open discussion is that people avoid ad hominem
attacks -- for example, they do not call people liars -- and they avoid

> etc. is a failure of the security model of SMTP.

The security model of SMTP is the same as the security model for sending
paper letters and for making phone calls.

To "fail" requires that there be a goal that was not attained.  That's not
the case here.  The case here is that real threats changed after 25 years of
operation and we need to adjust to them.

When crime goes up because a small town becomes a big city, and we have to
add locks to our doors, we do not say that the security model that used to
work "failed".  We say that it changed.

The key to open discussion is that people say things thoughtfully and with
an attempt to be accurate and precise.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Nov 2004 23:18:21 -0800

On Sat, 20 Nov 2004 17:38:56 -0500, Alan DeKok wrote:
> > Some major keys to open discussion is that people avoid ad hominem
> > attacks -- for example, they do not call people liars -- and they
> > avoid hyperbole.  For example:
>
>    To quote:
>   > you want to change the nature of the infrastructure. you want to
>   > redefine established terminology.
>   > In professional fora, it is entirely inappropriate to make assertions
>   > about other people's desires, capabilities, and the like.

It's difficult to imagine your believing that either of these two statements is on a par with calling someone a liar.  (Please note that the latter of the two statements you cite was, in fact, taking exception to a posting that also had indulged in ad hominem attack.)

So I'll guess that you are assessing them as hyperbole.  Again, it is difficult to understand how you consider either of the above statements to be hyperbole, on a par with calling a service that operated well for 25 years to suddenly be "broken" or to be a "failure".

>  things like "SMTP is imperfect", for fear of getting attacked.

The semantic difference between "imperfect" and "failure" is considerable.  Diligent consultation with a competent dictionary is encouraged.

Freewheeling use of inaccurate and excessive language is, indeed, a hallmark of public discussion about spam and anti-spam techniques.  

My point is that it prevents constructive discussion.

> > The security model of SMTP is the same as the security model for
> > sending paper letters and for making phone calls.
>
>    For one, you haven't explain why.  

For example, senders are not required to identify themselves in any of those systems.  Anonymous or misrepresented authorship is easy and common for all of them.

>   At the minimum, SMTP is electronic while paper

Well that certainly is an interesting assertion.  I can't imagine what makes it automatically true.

>  why the security models for SMTP and telephones would be the same.

Discussing why a popular security model might have serious inadequacies for a new environment is, of course, entirely reasonable.  But that's not what you are doing.

>    For three, my statement was talking about failures of a model, not

When you referred to SMTP you said nothing about a "model", nevermind a security model.  To the extent that you really meant to refer to a particular security model, then by all means please state that, rather than broadly describing that a long-standing, well-functioning protocol as a "failure".

>  the issue thar the security model of SMTP has had demonstratable

When messing around with global infrastructures, it is typically viewed as useful to worry a great deal about the base of experience with the model being used for that service and the model being proposed.  In that light, knowing that the existing model has extensive use in other global infrastructures is important.  

When you succinctly describe the proposed new model, you will discover that it has essentially no base of experience in a large scale.

On the average, it is considered important to worry about the impact of changes to a communication service, since the ability to communicate is usually taken as rather important for various aspects of human life.  So, for example, terminating the ability to communicate anonymously would have rather serious political ramifications.

>    SMTP as it was designed 10 years ago has failed to reach these new

23 years ago.

But really 32 years ago, since smtp is an evolution of the original ftp mail command.

>    This shouldn't be news.  It shouldn't be a sore point, either.

The sore point is not the limitations of SMTP.  The sore point is sloppy, inaccurate hyperbole.

>  it failed.  Without that information, it will be impossible to fix it.

It's unfortunate that you do see neither the formal incorrectness of the term "failed" nor the absence of substantive contributions about the nature of the changed threat and security models.

d/

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 21 Nov 2004 18:54:21 -0500

Dave Crocker <[email-masked]> wrote:
> When you referred to SMTP you said nothing about a "model", nevermind
> a security model.

  You mean this message, which you both read and responded to within
the last 24 hours:

 http://www.imc.org/ietf-mxcomp/mail-archive/msg05265.html
 > etc. is a failure of the security model of SMTP.

  My politest response is "You, sir, appear to be mistaken".

> Again, it is difficult to understand how you consider either of the
> above statements to be hyperbole,

  I don't consider them hyperbole.  You have, by your own standards
engaged in ad hominems towards me.  Yet when I repeated those phrase
back to you, it's me that you labeled unprofessional.  The word
"hyperbole" isn't applicable here.  Another word starting with "hyp"
is.

> on a par with calling a service that operated well for 25 years to
> suddenly be "broken" or to be a "failure".

  The phrase I've used is "SMTP fails to..", not "SMTP is a failure".
The difference is crucial.

  The terms "fails to" and "broken" are well-known, and widely used
in the security industry.  e.g. "With the advent of cheap computing
hardware, DES fails to provide adequate security for message traffic.
We suggest using AES".  Or, "With the advent of recent attacks, MD5
has been broken, or very nearly so."

http://www.google.com/search?hl=en&lr=&q=md5+broken&btnG=Search

  Which points to multiple links titled "MD5 broken".  If the authors
of MD5 had responded to those attacks with "A system in wide use for
many years cannot be properly described as 'broken'.", they would have
been laughed off of the planet.

http://www.google.com/search?hl=en&lr=&q=%22DES+fails+to%22+cryptography&btnG=Search

  Which points to an article containing the phrase "People understand
that DES fails to provide strong data confidentiality".

  Maybe SMTP is magic, and normal security terminology is inapplicable
here.  But I don't think that's true.

> When you succinctly describe the proposed new model, you will
> discover that it has essentially no base of experience in a large
> scale.

  The word you're looking for is "encompasses".  As in "The new model
of general relativity encompasses the old model of Newtonian physics".

  One goal behind creating a new model is to include all, or almost
all of the old model.  This automatically gives the new model a
large-scale base of experience.  Further, the reason for moving to a
new model is that there is a large base of experiences/data which are
known today, which aren't explained by the old model.  The new model
can explain them, giving it an even larger base of experience than the
old model.

  Science has worked this way for hundreds of years.  These model
development methods have also been demonstrated to be applicable to
many engineering fields, but are apparently not applicable SMTP.

> It's unfortunate that you do see neither the formal incorrectness of
> the term "failed" nor the absence of substantive contributions about
> the nature of the changed threat and security models.

  I've already dealt with the first part of that phrase.  As for the
second part, if my attempts to contribute to the field are so
blatantly absent or incompetent, there would be no need to put effort
into marginalizing me and my position.  You could just sit back, and
wait for everyone to realize for themselves that I'm an idiot.

  But the sheer effort put into marginalizing me exposes the reality
behind the concept that I have nothing to contribute.

> sloppy, inaccurate hyperbole.

  I may know less than you about SMTP, but I do know when I'm being
bushwacked.  Your attempts to stop my use of industry standard terms
and practices are duly noted.

   Alan DeKok.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 22 Nov 2004 03:50:45 +0100

John Levine wrote:

> The alternative is to take a big gulp of SPF kool-aid

The name of this beast is "reverse-path" in STD 10.

> decide that mail forwarding has, after 20 years, stopped
> being part of the way that SMTP mail works

| 251 User not local; will forward to <forward-path>
[...]
| The receiver takes responsibility for delivering the
| message.

Followed later by:

| The first host in the <reverse-path> should be the host
| sending this command.

> I hope we don't want to go there.

That's your decision.  I stick to the essence of STD 10.

The receiver is free to take the bounces (e.g. using SRS),
or he can reject my mail with 551.  But he should not say
MAIL FROM:<me> if it's actually MAIL FROM:<@receiver,me>.

The decision to break forwarding after 20 years is a side-
effect of RfC 2821.  Just like open relays it has to stop
now.  The spammers found this loophole:  "Hey, we can say
whatever we want in MAIL FROM after the real meaning of a
<reverse-path> was lost in cyberspace".

> If we want SPF, we all know where to find it.

Yes, RfC 2821 broke it, SPF "-all" fixes it.  BATV is an
alternative, it cures many symptoms of the same problem.

Sure, RfC 2821 only documented the loss of a real STD 10
<reverse-path>, and _that_ broke it almost beyond repair.
SPF "-all" can patch it for those who want it.  Like me.

> the EFF hasn't learned anything in the meantime.

That's putting it very mildly.  Let them join forces with
the DMA or whatever comes next.
                                Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 23 Nov 2004 10:22:02 -0500

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Alan DeKok" <[email-masked]>; "MXCOMP" <[email-masked]>
Sent: Sunday, November 21, 2004 2:18 AM
Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV.

> When you referred to SMTP you said nothing about a "model",
> nevermind a security model.  To the extent that you really
> meant to refer to a particular security model, then by all means
> please state that, rather than broadly describing that a long-standing,
> well-functioning protocol as a "failure".

We all know that SMTP has not been a failure.

What Alan is suggesting, for which I strongly agree, is that the focus in
solving the "problem" needs a revisiting of the SMTP model or more
specifically, the functional specification.   We have tried to "plug in"
ideas that simply fail to account for the entire MODEL for not only maximum
compliancy but for productive and maximum adaptability.  In some cases, we
attempted to plug in concepts that simply doesn't fit or is out of place.

Just consider this one very simple realistic fact:

A system that employs stronger SMTP compliancy enjoys a higher SMTP level
protection against abuse.

We have more than 1 year of steady on-going Anti-Spoof technology in place
with a consistent result on a
day to day, month to month basis.   A simple emphasis on compliancy will
provide you atleast a 60-90%
solution.   I can't dispute these.  These are the hard core empirical facts.

The point?

The majority of the problem is solved by concentrating at enforcing a new
level of "proper" operations.

We need to get over the "silly" arguments about what "MAIL FROM:" means.

We know what it means because its been operating in a consistent DEFINED way
for decades.

We need to be consistent.

If we discuss functional SMTP design flows for system notifications which is
based on the expectation that the return path is "usable"  then we need to
stop with idiotic suggestions that the return path is only "usable" at the
point is it required - a system notification, and not before then.     We
need to make sure the specifications makes it very CLEAR that the RETURN
PATH is expected to be valid, regardless of who it points too when it is
initially issued.   The idea of how a particular system may which to
implement that is an independent idea.  It has nothing to do with the
validity of it.

Now, can we improve SMTP to better describe what the RETURN PATH is?  user,
system, some list or whatever?  Sure, but what is common in all, is that its
a valid address.

Can we add new commands to help a "new process?"

I think so.  But we need to first look at what are the "holes" or factors
that are "missing" to help define what these commands should be.

Do we need to consider future payload transaction protocol methods?

Sure, I strongly think so.  This is one area I felt very strongly that
didn't not help Sender-ID, it failed to 100% recognize the payload issue and
how important that is.    But I personally see the payload issue in a bigger
concept than just for security, but for efficiency.

This is the kind of SMTP R&D WG discussion that needs to take place.  I
doubt this can happen in IETF-SMTP.  The type of people and attitude is just
wrong for it.  We need new open minded people who can think out of the
"box", and also understand the issues, and then with the help of the
'experts" like yourself,  help bring it all back together.   What we don't
need is are show stoppers who nix everything right at the start.

Once we get a consistent understanding of the issues with SMTP at each step,
removing the ambiguities, adding/merging BCP concepts/RFCs for "today"
operations, then we have a basis, an baseline, a framework to begin
implementing "Security Plug-ins" that will not only work better, but make
sense.

This may all sound simplistic to you, but that is what we need; getting back
to basics, taking a step back in the balcony.

The #1 improvement we can make or the IETF can make is a major cleanup of
the 2821 and related specifications as one new document.

Sincerely,

Hector Santos, CTO

---

From: Andrew Newton <[email-masked]>
Date: Tue, 23 Nov 2004 12:09:57 -0500

On Nov 23, 2004, at 10:22 AM, Hector Santos wrote:

> specifically, the functional specification.

That has been and still is the basis for all the disagreements in this 
area.

-andy

---

From: "Jeff McConathy" <[email-masked]>
Date: Tue, 23 Nov 2004 09:10:08 -0800

Awesome! you must have a better source than me ;)

---

From: David Woodhouse <[email-masked]>
Date: Thu, 25 Nov 2004 16:07:12 +0000

On Tue, 2004-11-23 at 12:09 -0500, Andrew Newton wrote:
> > What Alan is suggesting, for which I strongly agree, is that the focus 
> > in solving the "problem" needs a revisiting of the SMTP model or more

The nature of Alan and Hector's belief is such that it could only ever
really be disproven, and never proven -- even it if _is_ in fact true.

The existence of a solution which does not require the world to be
changed wholesale would disprove their theory that such change is
required. On the other hand, the lack of such a solution merely shows
that _either_ there isn't one, or it just hasn't been found yet.

As it happens, I believe that multiple such solutions _have_ been found.
They just need the details to be ironed out and the deployment to pick
up. There is a lot of merit in all of CSV, SES, BATV, DK, IIM and the
other solutions being discussed, and very little evidence that wholesale
changes to existing practice are required, such as the changes which
would be required by SPF or SenderID.

Thus, I believe that anyone who seriously wants widespread deployment of
a scheme to reduce the amount of faked email should put their energy
into assisting one of those schemes, and only if they all turn out to be
impractical should we revisit the possibility of requiring wholesale
changes to the existing email infrastructure.

There seem to be far too many people with a personal attachment to some
particular scheme, who don't really seem interested in pursuing which is
_technically_ more appropriate. I'd like to see a little less emotion,
and a little more rationality. 

-- 
dwmw2

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 25 Nov 2004 18:11:51 -0500

> really be disproven, and never proven -- even it if _is_ in fact true.

  I'm not sure which of my beliefs you're talking about.

> required.

  Ah.  You're not talking about any of my beliefs.  Do not use my name
in the context of opinions I've never held.

> There is a lot of merit in all of CSV, SES, BATV, DK, IIM and the
> other solutions being discussed, and very little evidence that
> wholesale changes to existing practice are required, such as the
> changes which would be required by SPF or SenderID.

  CSV, SES, BATV, etc. require *some* changes to SMTP.  To address
Andrew's phrasing of the disagreement, I ask "How can you change
things without changing them?"

  The existence of CSV, SES, BATV, etc. is an admission that the SMTP
model did not previously contain the ideas put forth in those
proprosals.  Therefore, whether people admit it or not, the SMTP model
*is* open for changes, and *is* being changed.

  The question now becomes: What changes are to be permitted, and who
is to be permitted to propose those changes?

  One answer is this: It's not 1984.  No one is proposing that X.400
or any other protocol should replace SMTP.

  SMTP has won the email protocol wars.  It has significantly more
deployment than any other protocol, and is therefore the only one in
wide-spread use on the Internet.  SMTP has a multi-decade track record
of being the best, the most useful, the most inter-operable, and the
most wide-spread email protocol.  To first order, nothing else exists
but SMTP.

  Once that's understood, it would be idiotic to replace SMTP with one
of the proposals which was discussed and rejected 20 years ago.  It
would be idiotic to go through SMTP, making massive changes to all
aspects of the protocol.

  What DOES make sense is to understand WHY spam is a problem in SMTP.
This involves re-visiting the model, because the model of SMTP as
created 30 years ago manifestly did not include the concept that "spam
is a problem."  We need to understand what's going on in the design
and deployment of SMTP which allows spam to be a problem.

  In the short term, we can come up with endless band-aids.  We can
play "whack-a-mole" with spammers.  But unless we look at the system
as a whole, we won't have a solution for the whole system.

  The most frustrating part of this discussion is that no matter how
many times I repeat my position, I still get accused of wanting to
replace SMTP with something completely different.  I still get accused
of wanting to "change the world whole-sale".  I still get told "we
can't change the model", even as the people saying that are changing
the model.

  It's not 1984.  20 years have gone by.  SMTP won those wars and all
of the protocol wars which followed.  No one is arguing that we should
replace SMTP with X.400, or any other non-SMTP scheme.  I'm not one of
the X.400 people.

  Get over it.

  Alan DeKok.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 25 Nov 2004 16:18:03 -0800 (PST)

> replace SMTP with X.400, or any other non-SMTP scheme.  I'm not one of

I've argued and will be happy to argue again that SMTP needs to be 
replaced with new protocol entirely instead of putting more and more
band-aids on 20 year old protocol that was designed for "simple" mail
transactions.

But creating new mail protocol to replace SMTP would take long time
(both in terms of IETF process to create this new protocol and process 
for it to achieve wide-spread adaption) and spam is a serious problem
in our current and immediate situation of using email so we have to
do something with what we have (i.e. SMTP) to get this under control
and only after that can we take a look at entire thing and see if we
can come up with something better taking into the account all the
lessons with have learned with what works and what does not in SMTP.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: David Woodhouse <[email-masked]>
Date: Fri, 26 Nov 2004 08:11:51 +0000

>   I'm not sure which of my beliefs you're talking about.

I'm talking about beliefs stated in the paragraph to which I was
replying, and which I quoted. In which Hector Santos used the words
"What Alan is suggesting, for which I strongly agree...". 

But it seems you were talking of problems with mail in general while I
was concentrating solely on spoofing, which is a special case -- one of
the band-aids you mention. I apologise for misinterpreting you and
attributing to you a belief which is not yours.

The same logical point applies though -- you can only ever demonstrate
that it _can_ by fixed without wholesale changes, by doing so. You can't
demonstrate that it cannot. 

But since no scheme to really _fix_ the generic problem without such
wholesale change exists, we're far more likely to give you the benefit
of the doubt when you say that such change is necessary. You're probably
right. It's not clear to what extent the change is needed, but you're
also right that it probably doesn't require throwing away SMTP and
starting again.

> in the context of opinions I've never held.

I apologise again for my misstatement. 

Are you saying you do _not_ believe that in order to fix the spoofing
problem we must make incompatible changes to the way SMTP works
universally? That you believe we can achieve it by only making changes
at the endpoint sites which want to take advantage of any new scheme?
That I would agree with.

> things without changing them?"

Perhaps I was overly ambiguous in an attempt to be succinct. Backward-
compatible change at _participating_ sites is fine. I'm speaking of a
need to 'upgrade the world wholesale' -- to force changes even at
uninterested and non-participating sites, because our new scheme relies
on assumptions about their behaviour weren't previously true. That would
be a very silly thing to do unless it's _really_ necessary.

Concepts like SRS and the proposed abuse of the 'Resent-From:' header
are the kind of thing I was referring to when I said 'change the world
wholesale'. Each would need to be deployed ubiquitously before the
scheme which requires them becomes truly viable.

> *is* open for changes, and *is* being changed.

Backward-compatible change within the scope of the existing system, yes.
Changing the model in the same way that MIME changed the SMTP model. How
many times do you remember demanding that some site out there upgrade
their mailer dæmon because you have started sending, or want to receive,
MIME mail? How long did it take them to 'upgrade'?

> is to be permitted to propose those changes?

Indeed -- and it's a very hard one to answer. What we _can_ say is that
changes which are limited to participating sites are a lot easier than
changes which must be implemented ubiquitously in order for the system
to work correctly. Hence we should eschew schemes which require
_ubiquitous_ change to current practice, in favour of schemes which can
be deployed incrementally at participating sites without losing
compatibility.

(That isn't to say that we should ignore a scheme which purports to
solve world hunger because it requires ubiquitous change, and we should
favour an alternative scheme which can solve just address spoofing
without such change. Obviously I'm talking about comparing schemes with
vaguely equivalent features.)

Compare SES/BATV with SPF, for example. Observe sourceforge.net (and
many other places) rejecting _faked_ MAIL FROM:<[email-masked]>
_WITHOUT_ having made any changes -- and when valid mail is forwarded to
a sf.net user from an account elsewhere, where the MTA in between hasn't
been changed either. Yes, it's a change to the model, but it doesn't
_require_ anyone else to adapt. That's the difference.

Likewise compare IIM with SenderID. Each purports to protect against
spoofing of the RFC2822 identities, but one was designed to work in the
real world today, and the other requires that the world adapt to fix it.

> or any other protocol should replace SMTP.

Some actually are, but it's entirely unrealistic. 

> as a whole, we won't have a solution for the whole system.

I agree with that. Hell, if we can have a practicable solution for the
whole system, I'll readily agree even to 'changing the world wholesale',
if that's actually required and realistic.

What I (and many others) object to is far-reaching changes which are
unnecessary; when we have alternative schemes which promise to achieve
the same goals, but without such change.

> can't change the model", even as the people saying that are changing

It does sound like I misinterpreted you in the same way, for which I
apologise. I'm not arguing with your actual position. To fix spoofing of
addresses is just a band-aid, as you said. But it's all that's on offer
right now. I'm saying we can do _that_ without fundamental changes. 

-- 
dwmw2

---

From: "Chris Haynes" <[email-masked]>
Date: Fri, 26 Nov 2004 09:16:21 -0000

> and a little more rationality.

Very good suggestion; let's get some rationality into this debate.

Let me bring to this august forum a debate which was happening in 'another
place' and see if we can re-visit it - because we need to find some kind of
resolution for it.

The problem is related to forwarding, and its interaction with Sender-ID (and
with SPF-Classic). I'll discuss the problem w.r.t. SPF (-Classic, because I
understand that better).

Please understand, I'm not inviting a reprise of arguments which have taken
place elsewhere, I'm trying to lift the level of debate to one of process
related to the 'definition' of SMTP.

I'll first just re-state the problem and give it bounds.

The problem arises with forwarding which undertakes the following sequence of
actions...

An entity does not wish to make widely available his 'true' eMail address of
[email-masked]', he employs a forwarding agency. He publishes the address
[email-masked].

A message originator  sends

HELO origin.com  MAIL FROM: [email-masked] RCPT TO:  [email-masked]

Now forwarding.com receives the content, consults its client database or
whatever, and places the content in a new envelope, sending it as

HELO forwarding.com MAIL FROM [email-masked] RCPT TO [email-masked]

Note that if the second message cannot be delivered to the [email-masked]
mailbox, a DSN 'bounce' generated by end.com gets sent direct to
sender:origin.com.

The bounce has details of the forwarding arrangements which 'sender' knows
nothing about, and 'forwarding.com' gets no opportunity to know that its
forwarding arrangements with the recipient are not working.

Now here's the central technical problem:

Suppose that origin.com has published an SPF policy.  That policy knows nothing
of forwarding.com and does not include any of forwarding.com's hosts among those
authorised to send on behalf of origin.com.

end.com implements SPF testing. It. too knows nothing of forwarding.com (so
cannot white-list it).

The forwarded message fails the SPF test, because the MAIL FROM claims that _the
second_ message is from origin.com, whereas inspection of its IP address shows
that origin.com has not authorised it to send message on its behalf.

Now, please don't reply by suggesting work-arounds, etc., or by saying that
scheme PQR avoids this problem. That's not what this message is about.

Let me focus on the heart of the debate, and I'm doing my best to be fair to
both sides here, and to use neutral language.

Still in the spirit of 'neutral language' , let me use the terms 'conservative'
and 'progressive' for the two positions I am aware of.

The conservatives look at the above example and say
"SPF is breaking the mail system. Forwarding has worked perfectly well in the
past; it is SPF which is changing; it is SPF which is wrong.  SPF should not be
deployed".

Again, let us ignore for now the possible work-arounds - just concentrate on SPF
in SMTP.

The progressives say:
"The world has changed, there are threats now which were never envisaged when
the SMTP protocols and practices were first deployed. Changes of some sort or
another _have_ to happen to regain the utility and trust that SMTP deserves."

The conservatives reply: "But not using SPF - SPF breaks forwarding".

To which the progressives reply:

"No. Actually, if you look at the SMTP architecture, as can be
reverse-engineered from the relevant RFCs, it is forwarding which is breaking
the SMTP architecture.

"forwarding (as per the above example) involves the transmission of two discrete
messages, with different envelope recipients. Yet what the forwarder is doing is
using the MAIL FROM of the first message when it sends the second message.

"It is wrong" (say the progressives) "for forwarding.com to use MAIL FROM
[email-masked]. SPF (rightly) detects this as an unauthorised use of
'origin.con', the second message is declared a forgery.

"It is also wrong" (say the progressives) "and has always been wrong - long
before SPF - that bounces are sent direct from end.com to origin.com.
forwarding.com should handle the bounce. Only if it cannot resolve the problem
should it notify origin.com, and it should not do this by sending a 'bounce'
back to origin.com, since. in the terms of the SMTP 'contract' to
'deliver-or-report' the message was correctly delivered to its intended mailbox
of [email-masked].", so no (2821-level non-delivery) report is
appropriate."

"Foul" cry the conservatives. "There was only ever one message involved. SMTP
has always supported more than one 'hop'. This 'two messages' business is just
not true.  Forwarding has always worked in the past, using the SMTP protocols.
There is nothing wrong with forwarding."

Some progressives propose to invite all forwarders to modify their practices so
as to conform to what they understand to be the SMTP architecture - and various
schemes have been suggested to help then do this in sensible, practical ways.

Conservatives accuse the progressives of mandating "wholesale changes to
existing practices" and requiring "changes which must be implemented
ubiquitously".

In this particular situation 'ubiquitous' (OED: everywhere or in an indefinite
number of places all at once) is an exaggeration.  It is only those forwarders
who re-use the originator's MAIL FROM who have to change, no-one else does; and
the progressives would claim that this is simply asking the forwarders to now
conform to the SMTP architecture.

Now, continuing in my attempt to be fair, let me withdraw any implication that
the conservatives are against any change whatsoever.  I'm using 'progressive'
and 'conservative' purely in the context of this one topic.

There are all sorts of problem-resolution schemes being proposed, and those who
oppose one may be a strong supporter of another.

But their is no ideal scheme on offer, anywhere.  All schemes will have plus and
minus points, all will require change of one sort or another. All change must be
evaluated rationally.

To return to the specifics of SPF and forwarding, the core question I wish to
raise here is this:
-------------

How, and from where, would one get an 'authoritative' ruling about the
conformance or non-conformance of  forwarding (using the origin's MAIL FROM with
a new RCPT TO) to the extant SMTP architecture?

Chris Haynes

---

From: Dean Anderson <[email-masked]>
Date: Fri, 26 Nov 2004 04:44:42 -0500 (EST)

First, I didn't participate in the FTC conference Mr Elvey seems to be
reporting on in his message, nor have I even made any comments on it, yet.  
Why I would be attacked in a report about an FTC conference is beyond
reason. Mr. Elvey is making a purely malicious attack on me in violation
of IETF and ISOC rules.

The following message by Matthew Elvey includes an inappropriate personal
attack in violation of the following sections of the ISOC Code of Conduct:
http://www.isoc.org/members/codeconduct.shtml

7  Only offer or claim to offer opinions or services that lie within the
   member's actual knowledge or competence.

8  In the case of financial or material conflict between personal and
   professional interests, or between two professional interests, declare
   this conflict to all interested parties and if appropriate in public.

9  Respect the generally accepted norms of Internet etiquette for human
   communications, especially by avoiding communications that are false or
   are likely to be considered as discourteous, objectionable, malicious,
   unwanted, or causing unjustified loss of prestige. Avoid fraudulent or
   deceptive statements.

11 Treat all users and colleagues fairly and on equal terms.

And the message violates the following sections of the IETF Guidelines for
Conduct RFC 3184:
http://www.ietf.org/rfc/rfc3184.txt?number=3184

1. IETF participants extend respect and courtesy to their colleagues
      at all times.

      IETF participants come from diverse origins and backgrounds and
      are equipped with multiple capabilities and ideals.  Regardless of
      these individual differences, participants treat their colleagues
      with respect as persons--especially when it is difficult to agree
      with them.  Seeing from another's point of view is often
      revealing, even when it fails to be compelling.
      English is the de facto language of the IETF, but it is not the
      native language of many IETF participants.  Native English
      speakers attempt to speak clearly and a bit slowly and to limit
      the use of slang in order to accommodate the needs of all
      listeners.

   2. IETF participants develop and test ideas impartially, without
      finding fault with the colleague proposing the idea.

      We dispute ideas by using reasoned argument, rather than through
      intimidation or ad hominem attack.  Or, said in a somewhat more
      IETF-like way:

            "Reduce the heat and increase the light"

=========================================================================
Message-ID: <[email-masked]>
Date: Sat, 20 Nov 2004 01:52:37 -0500
From: Matthew Elvey <[email-masked]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MXCOMP <[email-masked]>
Subject: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV.  
3)Dean  & FUSSP. 4)Testing 5)EFF, Anonymity.

[...]
=-=-=-=-=-=
3)Dean & FUSSP.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 26 Nov 2004 02:32:18 -0800 (PST)

Dean,

Without commenting on the details of your complaint may I remind you that 
this is no longer IETF WG mail list and so no longer operates under IETF 
rules. If you don't like something here, you should either contact mail 
list administrator (in private preferably) or simply unsubscribe.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 26 Nov 2004 06:11:21 -0500 (EST)

The IETF left the list operational at the request of members. So it is
still run 'under the IETF', and still under the IETF rules. The IETF and
ISOC rules apply to all IETF related activities, whether at meetings, bofs
or on IETF lists.

The list is however, not part of a working group, and thus cannot approve
RFCs.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Fri, 26 Nov 2004 11:04:17 -0500 (EST)

That DNSBLs are revenge-oriented is a court-established fact. Alan Brown 
of ORBS lost three lawsuits as an immediate result.  MAPS was successfully 
sued for blocking a non-spam site.   SPEWS is specifically organized to 
remain anonymous so that it can't be sued. Others have "reorganized" in 
foriegn counties to avoid suits (ORDB, ORBL)  Some have organized with 
college students  with no assets as operators to be immune from lawsuits. 

That the DNSBLs are very nearly universally abuse-oriented is also long
and well-established by history.  A frequent plaint on spam lists is
"Where can I find a good blacklist?" because there aren't any good
blacklists.  If they provided spam solutions of any sort, we wouldn't be
here.

See www.iadl.org for some history on abusive blacklist operators. See also
www.dotcomeon.com for volumes of information and press coverage on
blacklist operators and abuse committed by blacklist operators.

> http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-June/006933.html 

There is nothing particularly incredible about thest two above. I've 
outlined the information theory in detail, and have discussed it privately 
with PH.D's who've written seminal papers in the field of information 
theory. So far, no one has been able to find any flaw in the analysis, 
though it is still a ways from a formal proof.

Speaking of ranting:

Registrant:
   The Elvey.com IT Consulting Group
   3042 SacramentoGD ST, Suite 04. Illegally harvested
   from godaddy DB if mail received at this address
   San Francisco, California 94115
   United States

   Registered through: GoDaddy.com
   Domain Name: ELVEY.COM
      Created on: 21-Mar-99
      Expires on: 21-Mar-05
      Last Updated on: 14-Mar-04

   Administrative Contact:
      Elvey, Matthew  
EmailToThisAddressNotFromGodaddyIsSpamAndIsExpresslyForbiddenWithoutPayingAFee          
ToTEP.ByUsingThisAddressYouAgreeToTheseTermsOfUsage.YouAgreeToUseAllowOrEnableItsUseOnlyUnderTheTerm          
[email-masked]
      The Elvey.com IT Consulting Group
      3042 SacramentoGD ST, Suite 04. Illegally harvested
      from godaddy DB if mail received at this address
      San Francisco, California 94115
      United States
      (415) 555-1212 will provide the number      Fax --
   Technical Contact:
      Elvey, Matthew  
EmailToThisAddressNotFromGodaddyIsSpamAndIsExpresslyForbiddenWithoutPayingAFee          
ToTEP.ByUsingThisAddressYouAgreeToTheseTermsOfUsage.YouAgreeToUseAllowOrEnableItsUseOnlyUnderTheTerm          
[email-masked]
      The Elvey.com IT Consulting Group
      3042 SacramentoGD ST, Suite 04. Illegally harvested
      from godaddy DB if mail received at this address
      San Francisco, California 94115
      United States
      (415) 555-1212 will provide the number      Fax --

This guy thinks his address is illegally harvested if he receives Postal 
mail at his godaddy Postal Address.  That's pretty fringe.

Another hoot:
http://www.elvey.com/Spam%20Offer%20by%20Matthew%20Elvey.htm

And yet another that shows Mr. Elvey:
http://lists.essential.org/pipermail/am-info/Week-of-Mon-20001106/004270.html

Here's a quote of Mr. Elvey:

   "Hmm.  The owner of a company* that developed a version of Emacs once
    told me that GNU Emacs had tons of (unauthorized) source code from his
    company's product in it.  I don't know what the merits were (he
    appeared to be an upstanding guy!) but the point I want to make is
    that he decided that there was nothing his company could do about it.

    *which I don't think it would be appropriate to name in a public forum
    like this"

> and the results of #whois 130.105.36.66 and

And just what about the results of this query discredits me?  I suppose
you are unaware that the Open Software Foundation developed open systems
(Motif, OSF/1, DCE, Unix98, etc) and joined with the X Consortium (maybe
you've heard of the X Window System), and X/Open (XPG/4, SQL, etc) to form
The Open Group. I worked for the OSF for many years, and they are a
customer now.  They have made me authoritative for 130.105/16. 

Or perhaps you are just associated with the liars over at SORBS.NET, who
claim that 130.105/16 is stolen. They also claim that 198.3.136/21 is
stolen, too. But those are lies, and are just two reasons why DNSBLs are
(as you say) "terribly, horribly, drastically, irretreivably bad". I've
never said this. I've just said they engaged in revenge and are
untrustworthy, and that's been shown in many cases.

> if I'm skeptical about his statements.

For those who didn't bother, the site above has advertised a relay for
abuse for a long time. I even took that IP out of production server
(leaving a relay to collect the abuse generated by this "Dr. Moensted"'s
site.)  The URL referenced is a complaint about their unauthorized relay
testing, in which they sent 32 messages with fake headers, such as From
[email-masked], etc.  This URL is rather obscure, and probably
indicates an association between Mr. Elvey and the "Dr. Moensted", who is
actually just a kid, not a doctor of any sort.  We've gotten thousands of 
messages as a result of the "anti-spammers" false advertising.

So, forgive me if I'm skeptical of Mr. Elvey's statements. 

> functional and nearly spam-free is in the not-so-distant future.  

Vixie said this in 1996. We're still waiting. 

http://www.rhyolite.com/anti-spam/you-might-be.html

> 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.

Actually, "un-inventable" is exactly what information theory says about
it.  And it's no coincidence that thermodynamics was invented to dispel
the (concrete, as in spend money) proposals for building perpetual motion
machines. Just like the FUSSP proposals today. And its no coincidence that
information theory developed from thermodynamics, to figure out the same 
sorts of questions.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 26 Nov 2004 18:42:59 -0500

----- Original Message -----
From: "David Woodhouse" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "MXCOMP" <[email-masked]>
Sent: Friday, November 26, 2004 3:11 AM
Subject: Re: A new SMTP "3821" [Re: FTC stuff...........]

> right now. I'm saying we can do _that_ without fundamental changes.

And I'm saying you can not.

To suggest this, it is to presume that the solution is:

    - end point to endpoint, or
    - post smtp related.

Now, you might be thinking of a software (in fact, I'm sure you are) that
offer a "plug and play" capability, a mfilter or a ACL - but means change.

But it is more technically deeper than this and since you fail to recognize
all this,  it means
you are exhibiting a "emotional response," not I, to what has been pointed
out many times.

You (speaking in general) need to look at the mixed policy issues to
understand this better.  You need to look at each state point in the state
machine to see how it "fits" in the scheme being proposed or vice-versa.
What we have here are kludged solutions that may or may not have a "chicken
and egg" problem.

Believe it or not, good systems do not violate SMTP protocols.  It is only
the abusers that are taking advantage of the system.

The "fundamental" reevaluation of SMTP is not to "alter it" so that it
breaks the infrastructure, but rather to strenghthen what is already there.
For vendors in the market place, including our own, it is not in our best
interest to break customers operations.  Yet, we seek to secured it better.

In addition, as a vendor, I am very interested in supporting the mandates
imposed by our Federal Government laws such as CANSPAM - that means complete
email address validation and Topic Identification concepts.

Lets look at more specifics.  We have essentially one or more of the
following:

1) EHLO/HELO validation
2) MAIL FROM validation
3) RCPT TO validation
4) DATA validation, if any
5) Mixed Validation
6) No Validation at 2821
7) Post SMTP validation
8) Bounce Requirements

SPF concentrates on #2, and it lost on handling #1 and proper handling of
#5.  It ignores #3.

CSV concentrates on #1, gets lost on SMTP AUTH issues,  proper handling of
#5 and also ignores #3.

SENDER ID like SPF, also gets lost on #4.

IIM, YDK concentrates on #4.

Keep in mind that the above presumes "changes" to the SMTP system so that
the dynamic validation can be included at the transaction level.

Some of the schemes "may" also work in post-smtp mode, #7, which from a
practical standpoint offers a greater compatibility with the current
installed base.   However, this has proven to help the distribution of
SORBIG generation based e-viruses with #8 so it goes without saying today's
AVS ready system promotes dynamic RCPT TO validation #3.

I can go on and on with all the other schemes.  What they all have in common
are conflicts that are relaed to the ambitiguous, "which school of thought"
understanding of the SMTP protocol,  how SMTP is implemented in various
modes of operation, and many cases, a complete ignorance for efficiency.

So what I have been proposing since day 1 is let us  revisit the protocol,
not with a desire to fundamental change it  but with a GOAL to better grasp
the state machine and how it is being
exploited at each state state and also as a mixed policy.

The goals are:

- To remove the ambiguity on the functional specification.

- Introduce the functional specification for state machine validation.

- Introduce, if any, new ESMTP protocols to help augment the new SMTP
security requirements.

Note I did not say "technical specification."  There is a major difference
in functional vs technical specs.

We need to remove the "comments" in the specs that suggest "lets not break
the system because of one abuser."  In other words, we need to change the
"old spirit"  of a loosely guarded network of nodes to one that is more
mature for today.

Now, we can ask, why do we want to do this?

Well, you want to do this now only to better understand what are the key
issues and how to improve it, but to also allow for the R&D and future
developers to have a better summary document to design SMTP software.   Of
course, you can also say "Why write a new SMTP server when you have open
source to work with?"       Well,  many times, people need to write
proprietary systems.

But this is would be going off on a tangent.   The key issue is
understanding the problem in order to solve the problem.  Band-aids, while,
they can work,  what is quite evidence, they lack analysis of how it will
actually work within the "current infrasture."

I leave you with one example:

IIM/YDK,  what if a message is properly signed with a proper address by the
outbound system, does this mean the client domain name can still be invalid?
What if it is not valid?

While you may be looking for a partial solution, I on the other hand am
looking for a real solution. And yes, I have a full understanding that may
not be practical, but at the very least, it is in my nature as an engineer
to gain a full understanding of the problem first to better analyze the
theorical as well as the practical solution.

Sincerely,

Hector Santos, CTO

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 26 Nov 2004 19:54:43 -0500

"Chris Haynes" wrote to David WoodHouse:

> ....

Good analyze and examples of the different viewpoints.  You emphasized on
the classical forwarding/routing problem currently experienced by the LMAP

> a new RCPT TO) to the extant SMTP architecture?

The more fundamental question as I see it is:

Does the process allow for "information" to be available so that a downlink
can understand what has occurred at a transition point?   If so, when and
where?   If no, when and/or where it is exposed?

On specifics,  The SUBMITTER proposal lends itself to this forwarding
problem.  But it only works in compliant downlinks.  The DMP (LMAP) also
lends itself using the secondary HELO/EHLO LMAP check when the 2821.MAILFROM
LMAP check fails.  But it presumes a working DNS secured/exposed HELO/EHLO
client domain name.

The question I ask (rhetorical) is what "common ground" SMTP level 'trace"
information can be done to better transition points.

I believe the Received: header lines are our "best"  hopes.  However, this
requires a PAYLOAD transaction.

In any case,  no matter how I look at the solutions, it always comes down
for a downlink to have more information at the transaction SMTP level.

A new ESMTP HEAD command keeps common to mind.  It solves many of the issues
we face, it will help the IIM/YDK and SENDER-ID proposals.  It will help
resolve the "transition points" forwarding problem.   It will help new ideas
such as TOPIC identification concepts.  I believe very strongly, this would
be a great enhancement to the protocol.

The expert debaters can argue the merits of how compatibility is address.
My simple input here is that ESMTP advertisement indicates a level of
scrutiny/security based on compliance.  For example, in response to EHLO, it
can have:

HEAD       - Optional
HEAD-R    - Required
HEAD-S    - Optional  for SPF systems
HEAD-A    - Required for ANONYMOUS senders

etc, don't know, this side of it needs a good analysis.  But it is on par
with the idea of new systems enforcing new requirements, and new systems
also offering some level of backward compatibility.

Sincerely,

Hector Santos, CTO

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 28 Nov 2004 10:23:41 -0500

> I'll first just re-state the problem and give it bounds.

  That's the best summary I've seen to date.  My question now is,
(using the generic "you"):

  What do you mean, the "same" message is being forwarded?

> How, and from where, would one get an 'authoritative' ruling about
> the conformance or non-conformance of forwarding (using the origin's
> MAIL FROM with a new RCPT TO) to the extant SMTP architecture?

  I would like an answer to that question, too.

  .forward files are not required for SMTP to work.  Entirely
equivalent functionality can be obtained without using a third parties
name in "MAIL FROM".  That functionality requires changes to the sites
using .forward files, and nothing else.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 28 Nov 2004 10:12:32 -0500

> attributing to you a belief which is not yours.

  Thank you.  I can't ask for anything more.

> universally?

  I've seen no evidence that such a change is required.  However, IF
there are no better methods, then I am prepared to accept that such a
change is required.

  For many discussions I've been involved in, people ignore the "IF",
and go on a tangent.  That's been a serious source of
miscommunication.

> That you believe we can achieve it by only making changes at the
> endpoint sites which want to take advantage of any new scheme?

  I hope that's true.  It certainly looks that way.

> > Therefore, whether people admit it or not, the SMTP model

  Again, who decides what's in scope, and what's not?

  If my domain has no users with ".forward" files at other domains,
then implementing RMX/SPF/whatever doesn't break forwarding for *my*
users.  The argument against those proposals then becomes "We have
.forward files, so we won't be implementing RMX, and we don't want you
to implement it, either".

> [ re: who can propose what changes ]
>
> to work correctly.

  As a toy proposal, a simple solution to the .forward problem is to
replace the .forward files with a script, which adds a header like:

X-RFC2821-Original-Bounce-Path: <rcpt-to mailbox>:<mail-from mailbox>

  The script can then send the message, using the original "rcpt-to"
as the new "mail-from", and accept the bounces.  When a bounce comes
back, the script can look for it's name in that field, and bounce the
message in turn to the original "mail-from".

  Add some authentication so the field can't be spoofed, maybe some
encryption so it's private, and a site using ".forward" files can
upgrade them all to a functionally equivalent form, which does NOT
require using a third parties name in "MAIL FROM".  No interaction
with other sites is required.  Anyone familiar with Sendmail's rules
could probably add something like that in a few hours, and most users
wouldn't even have to update the contents of their ".forward" files.

  The only reason that people were using .forward files is that it was
easy, it worked, it didn't cause problems for other people until
recently, and there is always resistence to change.

> I'm not arguing with your actual position. To fix spoofing of

  Yes.  But there has been near-zero discussion about what the "SMTP
mode" really is.  The current SMTP "model" is a collection of RFC's,
implementation decisions, deployment decisions, and other ideas in
peoples heads.  For the model to be clear to everyone, the concepts
have to be written down, and explained for everyone too discuss.

  The alternative is to allow only the people with the "secret decoder
ring" to discuss or update SMTP.

  Alan DeKok

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 28 Nov 2004 13:37:07 -0800 (PST)

> X-RFC2821-Original-Bounce-Path: <rcpt-to mailbox>:<mail-from mailbox>

Although longer, below header provies a better annd more complete view 
(for debugging) on what happened and who did the forwarding:

Redirected: by <.forward host system name>
  on-behalf-of <user at .forward host system>
  process-type forwarding
  original-envelope return-path=<mail-from mailbox before fowarding>
                    recipient=<rcpt-to mailbox before forwarding>
  new-envelope return-path=<mail-from mailbox after fowarding>
                    recipient=<rcpt-to mailbox after forwarding>; time-stamp

See http://www.ietf.org/internet-drafts/draft-leibzon-emailredirection-traceheaders-00.txt
 note that it was published with bad new lines, for correct text see
http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00.txt
 and for printable format see
http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00.pdf

As for Original-* headers, the standartization of their use is TBD in
one of my next drafts. For what you wanted, I'll recommend using
"Original-Envelope-From" (this is actually already being used) for
return-path and "Original-Envelope-Recipient" for RCPT TO. But obviously
for reporting original values before forwarding/redirection I'd prefer
people start using Redirected trace headers.

>   Add some authentication so the field can't be spoofed
Email signature can be addded above in a way similer to what DK proposed, 
stay tuned to mailsig mail list tomorrow.

> recently, and there is always resistence to change.
It still does not cause problems for other people!

What SPF is now doing is saying that .forward need to do more then just
simply relaying message with new addresses and need to identify who they
are and what they did. This is good for better email security although
people who want to remain anonymous might not like this trend (as usual).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 29 Nov 2004 11:16:14 +0100

On Fri, Nov 26, 2004 at 04:44:42AM -0500,
 Dean Anderson <[email-masked]> wrote 
 a message of 92 lines which said:

> The following message by Matthew Elvey includes an inappropriate
> personal attack in violation of the following sections of the ISOC
> Code of Conduct: http://www.isoc.org/members/codeconduct.shtml

Welcome, Matthew, on the blacklist of Mr Anderson. People are hereby
informed that Mr Anderson is a world-renowned expert on complaining
about personal attacks. Indeed, googling on "anderson complaint ietf
personal" will show that his personal hall of shame if quite large :-)

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 29 Nov 2004 10:53:58 -0500

> (for debugging) on what happened and who did the forwarding:

  Sure, there are a whole host of similar solutions, some of which
were developed with more than 5 minutes thought. :)

  The simple addition of a header allows .forward files to work, and
requires no off-site changes.

> return-path and "Original-Envelope-Recipient" for RCPT TO.

  To be robust, they have to be tied together, and they have to be
able to have multiple copies added across multiple ".forward" hops.
The Redirected: header you propose is much better at doing that.

> people who want to remain anonymous might not like this trend (as usual).

  It's not just SPF.  It's a way to address the spam problem.  As
Hadmut has said, stopping forgery requires everyone to give up
forging.  If I didn't agree to let others use my domain name in "MAIL
FROM", it's forgery, because *I* define the use of my domain name.  If
someone else doesn't mind, that's their issue.

  And what do you mean by "anonymous"?  To send SMTP, you HAVE to have
a routable source IP address.  This means that the SMTP server you're
talking to knows who you are, and that knowledge is probably going to
be put in a Received: line in the SMTP message.

  If an "anonymous" sender has no reverse path, then they can't accept
bounces, and no one can respond to their messages.  To me, this means
a protocol other than SMTP is better suited for anonymity.

  The lack of a definition for ideas like "anonymity" in relation to
SMTP is one of the causes of miscommunication.  Everybody uses the
term, and everybody "knows" what it means.  But in the absence of a
quantitative definition, none of the definitions are talking about the
same thing.

  Alan DeKok.

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 29 Nov 2004 11:17:18 -0500

My apologies to the list. My failure to follow my own advice:

> Dean Anderson of av8 seems best largely ignored...

has proven what good advice it was even better than the evidence I had 
provided.
It won't happen again.

---

From: Meng Weng Wong <[email-masked]>
Date: Mon, 29 Nov 2004 13:40:06 -0500

I want to thank Chris Haynes for his summary of
"conservative" and "progressive" positions.
I have recorded a very similar summary on page 16 of
http://spf.pobox.com/whitepaper.pdf

On Sun, Nov 28, 2004 at 10:23:41AM -0500, Alan DeKok wrote:
| 
| > How, and from where, would one get an 'authoritative' ruling about
| > the conformance or non-conformance of forwarding (using the origin's
| > MAIL FROM with a new RCPT TO) to the extant SMTP architecture?
| 
|   I would like an answer to that question, too.
| 

I wonder if we could ask the IESG to vote on it.

|   .forward files are not required for SMTP to work.  Entirely
| equivalent functionality can be obtained without using a third parties
| name in "MAIL FROM".  That functionality requires changes to the sites
| using .forward files, and nothing else.

BTW, verbatim forwarding is practiced not just by unixheads
with .forward files, but also by hosted domains, of which
there are millions in existence, and alumni / lifetime email
services like alumni.*.edu and acm.org.

The hosting providers can implement workarounds, and
forwarding service providers can implement workarounds.
From the receiver end, trusted-forwarder.org lets receivers
whitelist forwarding hosts.

That leaves only the ad-hoc forwarding setups.  For those
cases, I would like to be able to tell them "just upgrade".
Shevek has been leading the effort to get SRS into MTAs.
For 2005 I plan to expand that MTA-patching effort to
include the Leibzon trace headers and MS's Resent-*.
(DK+IIM will be part of the patch effort also.)

That is where things stand as of November 2004.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 29 Nov 2004 11:47:48 -0800

On Fri, 2004-11-26 at 15:42, Hector Santos wrote:
<snip>
> CSV concentrates on #1, gets lost on SMTP AUTH issues,  proper handling of
<snip>

CSV only ensures the EHLO/HELO can be authenticated and does not hinder
other authentications.

"Concentrates on validation" does not define what is provided.
Authentication is different than offering authorization lists and
presuming the entire system is secure.

There is a fair amount of information obtained with the specific
authentication and authorization made available with CSV.  With this
information, a specific domain is indeed accountable for the host and
has authorized the sending of mail.  With this authenticated name, other
associations can be safely made.

BATV is useful to protect related network resources of the return path. 
CSV is useful to protect the related network resources of the recipient
path, when used with a reputation service.  Digital signatures are
useful to prevent domain forgeries and to also establish
accountability.  Schemes that require the processing of the message do
not offer network resource protection however.

There are safer solutions for path registration, but such schemes are
not useful for locating security problems or for application of a
reputation service.  Messages that have only been authorized, but not
authenticated, is not sufficient to establish accountability as a basis
for reputation.
   
-Doug

---

From: Dean Anderson <[email-masked]>
Date: Mon, 29 Nov 2004 18:00:16 -0500 (EST)

And speaking of the complain
On Mon, 29 Nov 2004, Stephane Bortzmeyer wrote:
> about personal attacks. 

Really?  Well, I suppose it is because I debunk world renowned bullshit 
artists.

> Indeed, googling on "anderson complaint ietf personal" will show that
> his personal hall of shame if quite large :-)

Actually, the list of abusers is not all that large. However, I notice
that Stephane Bortzmeyer is also on it. So, I guess that his message here
is more self-serving that it first appears.  But wait, lets take another
look at Bortzmeyer's abuse:

Stephane Bortzmeyer wrote
>> If Av8 turns on PPLB, traffic to F-root will go through both sprint
>> and att on a per-packet basis.
>
>Troll Bot <[email-masked]> keeps mentioning PPLB. May be some people
>more knowledgeable about BGP than I am will explain to me why PPLB is
>such a new issue for anycasting?

BTW, It turned out that I was right on this issue, and the Bortzeyer was
just being an idiot, and who didn't even know what PPLB was, and who was
unable to formulate an intelligent opinion in the first place.  In the US,
we have a phrase that describes this behavior:  It's called "talking out
of your ass".

So it seems Bortzmeyer and Elvey are in the same group.  Funny, that.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 29 Nov 2004 18:19:30 -0500 (EST)

It is interesting that there is still no explanation of what the attack on 
me has to do with the FTC.

I think its more appropriate to ignore someone who claimed that GNU emacs
contained much pirated code (Elvey, 2000).

That claim evidences such profound ignorance of 
	history,
	emacs,
	GNU,
that there is no basis for intelligent conversation with such a person.  
They are either completely ignorant, or compulsive liars, or both.

I am relieved to see Elvey and Bortzmeyer getting along so well. Like peas
in a pod.  Same pod.  Probably the ignorant compulsive liars pod, shared
with Vixie, Alan Brown, and Matthew Sullivan.

		--Dean