Subject: RE: digital signature request

From: [email-masked]
Date: Wed, 25 Feb 2004 13:35:00 -0800

On 25 Feb 2004 at 12:16, Neil Carpenter wrote:

> > the value in having the list processor sign all posts
> > is simple.  guaranteed identification of the list
> > traffic for any recipient who decides to verify
> > signatures.
> 
> This seems to solve a non-problem.  Unless there are spam messages that
> where the sender has, for instance, forged the existing "Sender:
> [email-masked]" header, signing these messages will add nothing of
> value.  It seems much more likely that a spammer would simply send
> e-mail to the [email-masked] list & allow the list itself to propagate it
> than that they would specifically forge that header.

again, i'm not imagining that having the list 
processor sign all mail will stop spam from entering 
the list.  the problem i need to solve is how to stop 
spam from being sent *directly* to me.  accepting only 
email with whitelisted signatures will solve my 
problem.

btw, i thought you needed to be subscribed to the ietf 
list prior to being able to post to the ietf list?

On 25 Feb 2004 at 11:26, Stephen Sprunk wrote:

> You have yet to demonstrate the problem you are trying to solve even
> exists.
> 
> I've gotten over 2700 spams this month, and zero of them have "ietf"
> anywhere in them, either header or body.  Thus, I see no compelling
> reason for the ietf's list software to sign anything when a simple MUA
> filter on the Sender: line already achieves 100% accuracy.

see above response.  also, from my perspective digital 
signature verification is simpler than maintaining a 
filter list.  i'm tired of the spam/anti-spam arms 
race.  i'm going to deploy a solution that is 
unspoofable.

On 25 Feb 2004 at 12:06, Vernon Schryver wrote:

> > From: [email-masked]
> >
> > > Having the latest tools means nothing, unless
> > > they are used right.  Are 
> >
> > i'm using them correctly
> 
> I, for one, am unconvinced.  I have had no trouble
> filtering unwanted mail from this list, thanks to
> procmail.  My various filters have no trouble
> dealing with more than 99.9% of the unsolicited bulk
> mail including viruses and worms directed at my
> mailbox.  For my mail, my filters have a total false
> positive rate (legitimate rejected divided by total
> legitimate) of less than 0.1%.  Whether your filters
> are doing as well as you want them to does not seem
> like a concern of the IETF.

i have ~98% accuracy thanks to bayesian filtering.  i 
haven't calculated my false positive rate, but i get 
false positives.  even *one* false positive is 
unacceptable.  even if my filter accuracy was 99.99% i 
would still need to trawl my spam folder to check for 
false positives.  and as the spam volume continues to 
grow trawling the spam folder takes more and more 
time.  i need to stop false positives and digital 
signatures are one possible solution.

> > ...
> > the value in having the list processor sign all
> > posts is simple.  guaranteed identification of the
> > list traffic for any recipient who decides to
> > verify signatures.
> 
> I think it would be simpler for all concerned and in
> this case just as effective if the IETF list
> processor would offer to do SMTP-TLS and for an
> appropriate cert to be published on http://ietf.org/
> 
> However, I would not suggesting that for any
> practical or operational reason.  It would merely
> set a good example.

i'm not familiar with SMTP-TLS but i will go read 
about it.  FWIW, i think that digitally signing all 
list messages would also set a good example, and it 
too is a simple implementation.

david

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 25 Feb 2004 15:41:21 -0700 (MST)

> signatures are one possible solution.

Digital signatures cannot stop false positives.  Even if all mail were
digitally signed, there would still be cases where the wrong key was
used, the right key did not reach the mail recipient before the mail
message, a cert expires, or something else hiccups.  The underlying
error rate for SMTP before spam appeared was worse than 0.01%.  Do you
think that 99.99% of HTTPS (HTTP over TLS or SSL) transactions work?
If so, look again.  If not, why would email be better?

If you cannot afford even one false positive, then you had better give
up on email.  My spam load is more than 300 messages/day, counting
only unsolicited bulk advertising.  I receive 50-150 legitimate messages
per day.  It would be impossible for me manually filter that stream
to 99.99% accuracy and so overlook fewer than 1 legitimate message per
10,000 or fewer than one per month.  No one can look at 10,000 messages
per month, never misclassify any as spam or not, and do any other work.
Talk about not losing even one message makes sense only if you receive
almost no spam.

People who talk about 99.99% accurate spam filters as if they were
possible
  - don't know how computers work in the real world (e.g. have no idea
      why the phrase "key distribution" makes some people cringe or
      assume the tooth fairy handles key revocation)
  - don't receive much spam
  - are innumerate
  - are charlatans.
  - are two or more of the above.

At least weekly I'm told of yet another final ultimate solution to the
spam problem with 100% accuracy.  They are all frauds, like weight loss
diets without hunger or any other inconveniences.  Sometimes they have
creative definitions of "spam" and "false positive."  Usually they are
merely obvious wishful thinking and nonsense, like the hoary old claim
that authentication (including digital signatures) will stop spam.

Vernon Schryver    [email-masked]

---

From: "Jake Nelson" <[email-masked]>
Date: Wed, 25 Feb 2004 21:55:53 -0600

> race.  i'm going to deploy a solution that is

No, you aren't. You're quite welcome to try, however... anything that slows
the spammers down is progress.

-- Jake

---

From: "Robert G. Brown" <[email-masked]>
Date: Thu, 26 Feb 2004 09:05:42 -0500 (EST)

> signatures are one possible solution.

But they aren't.  They won't stop false positives and they won't keep
you from having to traverse your spam folder if your criterion is "no
false positives".  

As has been pointed out, it is effectively impossible to make a filter
that passes only signal and no noise, only desired communications and
never undesired (especially given that the final decision is essentially
human and subjecting and too complex for ANY filtering tool but your own
mind).  There is real math behind this, but it is really a common sense
conclusion as well.  So if your criterion is "no false positives" (a
goal that is up there with a 100% efficient heat engine, winning the
publisher's clearing house sweepstakes, and a free lunch:-), not only
will you need to trawl your spam folder, you'll need to trawl it
repeatedly, as you yourself probably make mistakes on what is spam and
what isn't one in 10^4 or 10^5 times, if not more, especially on a rapid
scan of hundreds of messages almost all of which are spam.

It has been pointed out several times now that unless you are willing to
receive mail only from a small, closed group of individuals that all
agree to use digital signatures and whose mail you whitelist while
blacklisting EVERYTHING ELSE you are right back where you are right now.
Since you don't blacklist everything else, it gets filtered (or not) and
you have to go through the rejects in a final pass.  Who knows, one of
them might be your long lost cousin Jimmy, trying to get in touch with
you but alas not possessed of either your phone number, a digital key
and knowledge of how to use it, and hence the means to communicate it to
you and hence get on your whitelist.  It requires an out of band
communication for him to be admitted to your channel, and if you reject
everything not in your channel, Jimmy's out of luck.  

Then there is the cruel fact that you aren't going to convince all the
list managers in the world to digitally sign their list traffic.  You
can of course decide never to subscribe to a list that doesn't, but that
throws a whole lot of baby out with the bath water, and again leaves you
trawling rejects.

The only issue in controlling spam is whether one BOTHERS to trawl the
rejects.  This, in turn, is related to the level at which you reject
spam -- the ratio between false negatives (spam that makes it to your
regular spool) and false positives (mail that makes it into your spam
spool).

I set my spam filtering high enough that I don't check the rejects.
I've spot-checked the rejects for quite some time, and any "real mail"
that gets rejected is VERY likely to be something I will survive if I
never get, and if it IS important and for any reason the sender is a
friend they will almost certainly send me an out of band communication
in my mostly OPEN filter channel saying "Hey, why didn't you respond to
my note letting you know that you won the sweepstakes in Nigeria and are
about to be presented with a check by the grandson of its prime
minister?  I put a dozen URL's to the website announcing the result into
the message when I sent it from my laptop through the open WiFi net I
happened to be passing by..."

Others set the filter lower, but quick-scan the rejects.  Still others
might set one breakpoint VERY high (and reject 70% of it out of hand
with "no" false positives), set a second low enough that no spam at all
makes it into their regular spool, and quick scan the intermediate
rejects.  Just by examining the SA rating of spam that makes it through
and the rating of regular mail that makes it through, it is pretty easy
to see whether or not your active boundary is reasonable.

Digital signatures won't change this a bit.  It may permit you to
identify a certain class of true negatives (and keep them out of the
false positive bin), although I at least am cynical about even that.  It
won't keep you from having a wide range of mail that you still have to
filter and still have to review, if your criterion is "no false
positives" and you want to remain globally accessible to mail from
strangers, and the additional work it will require to implement so that
you can even afford to implement it at all greatly exceeds the work
you're doing now, or could be doing with a bit of rearrangement.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:[email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 26 Feb 2004 08:29:07 -0700 (MST)

> From: "Robert G. Brown" <[email-masked]>

> blacklisting EVERYTHING ELSE you are right back where you are right now.

If you are interested in that model, then you do not need any fancy
cryptography, certs, pretty good encryption, S/MIME, or anything else
not already present in all SMTP mail.  You can whitelist using bits
that are already associated with every SMTP mail message and in
the body delivered to your MUA if your MTA is not broken junk.

Ever mail message carries a practically unforgeable (for spammers)
token identifying its source.  That token is the IP address of the
SMTP client.  If your MTA is reasonable, it is included in the Received
header it adds.  You only need fancy extra stuff if you cannot arrange
for your community to use only trustworthy MTAs or if your traffic is
worth the thousands of dollars (or equivalent labor) that breaking
security based on IP addresses requires.

Yes, I've heard of Bellovin, Mitnick, RFC 1948, etc. so forth and so
on and on.   TCP ISN faking is harder now than it used to be.  It was
always incompatible with the "bulk" in "unsolicited bulk mail."

The spam problem starts with accepting mail from strangers.  Give
up that design goal, and spam disappears.  So does much of the
justification for mail.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 Feb 2004 16:43:39 +0100

> blacklisting EVERYTHING ELSE you are right back where you are right 

If we can communicate the fact that a message is discarded because it 
was categorized as spam back to the sender without adverse side 
effects, then occasional false positives aren't much of a problem.

As for signing list messages: some practical experience would be good 
here. I'm not sure this list is the best choice to gain it, though.

---

From: Ed Gerck <[email-masked]>
Date: Thu, 26 Feb 2004 08:51:20 -0800

Vernon Schryver wrote:
> 
> The spam problem starts with accepting mail from strangers. 

This phrase is a good soundbite. I'd add:

The spam problem starts with *freely* accepting mail from strangers. 

If we force strangers to jump some hoops before their email can reach 
our mailboxes, it seems clear to me that we can still keep receiving 
email from strangers. Accountability (as in the "email caller ID" proposal 
by Microsoft) and identification (by requiring digital signatures) are
not enough. They are locally restricted in the application of laws, jurisdiction, and enforcement. Rogue messages due to spoofing, worms and 
virus cannot be prevented either. Spam could still contaminate list
traffic, even if list messages are signed by the listserver. Rubbish
in, rubbish  out.

Even though the pain is at the output, the problem is not at the 
output. The problem is at the input, when we freely accept email 
from strangers.  We need to provide mechanisms (plural) for 
selectively locking the input.

Comments?

Cheers,
Ed Gerck

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 26 Feb 2004 10:28:32 -0700 (MST)

> From: Ed Gerck 

> email from strangers. 

That is the e-postage and other...I'm sorry but the best phrase is
"snake oil."  There is no and can never be a hoop that is low enough
to pass enough human strangers but exclude spammers' computers.  If
your hoop passes mail from
  - the deaf
  - the blind
  - those who don't understand the spoken form of your native tongue
      as well as a computer
  - those who don't use graphics (e.g. lynx)
  - whose whose computers don't play audio files (mine doesn't)
  - those who don't have computers made within the last 5 years
  - the tired, confused, or intoxicated
  - the lazy or disinterested
  - the mentally challenged or just plain stupid
then it will also pass mail from spammer's computers.

The idea of forcing your correspondents to jump through hoops that
spammers' computers can't is fundamentally wrong and crazy.  If there
is one good characterization of the difference between human and
mechanical minds it is that machines are far better at jumping through
hoops than we are.  Computers are happy to try a bazillion times until
they get it right.  We get bored.  A spammer's computer will happily
continue trying to guess the answer to your puzzle as long as you let
it, or look for it in a crib sheet of 1,000,000,000 clues.  We not
only won't; we can't.

Only the meta-hoop of fear of prosecution might work.  419 spam
demonstrates its severe limitations.

---

From: Ed Gerck <[email-masked]>
Date: Thu, 26 Feb 2004 10:31:20 -0800

Vernon Schryver wrote:
> spammers' computers can't is fundamentally wrong and crazy.  

Correspondents are also computers, humans don't do SMTP. 

> A spammer's computer will happily continue trying to guess the 
> answer to your puzzle as long as you let it, or look for it 
> in a crib sheet of 1,000,000,000 clues. 

Spammers need scale (because they get a very low return). Therefore,
part of the solution should be to deny scalability to spammers. You 
seem to think that is not possible. However, it is trivial for a 
receiver to impose and enforce *both* work and time burdens to receive 
emails from strangers -- at the MTA *and* at the MUA levels. 

For example, my MTA could enforce large time delays at every step to 
complete the SMTP session if the headers contain something suspicious 
like "Received: from ([127.0.0.1])". Also, my MTA could require message 
encryption and/or MAC using *my* PK (imposing a burden per message). 

Look up tables and computational power cannot help spammers in such
case. "Jumping through the hoops" is not optional and will take work
and time, that my MTA can increase at will -- as much as might be 
necessary to be an effective deterrent to abuse by strangers.

Cheers,
Ed Gerck

---

From: "Robert G. Brown" <[email-masked]>
Date: Thu, 26 Feb 2004 14:45:21 -0500 (EST)

> emails from strangers -- at the MTA *and* at the MUA levels. 

  a) Moore's law

  b) Economics

  c) Arithmetic

  d) Clustering

  e) Human nature

among many other reasons why this idea will not fly.  

Work and time burdens are not uniform or static because of Moore's law
-- a modern system might be eight to thirty-two times more powerful than
a nearly obsolete system on the same network.  Are we going to deny
people on the obsolete system the ability to send mail because we're
trying to slow down the fastest system enough to make a difference?

Economics alone would crush the idea.  A large institution is already
paying large sums of money supporting its primary MTAs because they are
receiving hundreds of thousands to millions of messages a day.  You
propose to ask them to what -- double?  triple?  ntuple where n is
whatever integer you think it has to be to STOP SPAM?  They'd implement
institutional-level MTA-based spam filters before they did that -- it
would be cheaper.

Then there is arithmetic.  What, exactly, is enough of a work burden
sufficient to be a burden to a spammer?  A spammer who sends anywhere
from 10000 to 10000 messages a day can make money, from what I've read.
That is order of a message every 1 to 10 seconds, and very little of
this time would be spent consuming bandwidth.  Note that this is a
tens to hundreds of times as much time as is currently required, and is
NOT easy to arrange.  Since the amount of arithmetic determines the
ntupling of server expenses for every large mail operation on the
planet, you are facing pressure from above to keep it cheap and from
below to make it effective.

Clustering, alas, will frustrate you.  A spammer can afford to add cheap
hardware for solving the problem at the high end of Moore's Law faster
than legitimate shops can afford to add expensive and reliable hardware
to handle enterprise mail.  It won't even cost them more bandwidth,
since they can easily make their 100K/day nugget with a fairly cheap ISP
connection fronting their whole cluster.

Finally, there is human nature.  You proposed solution is cumbersome and
expensive, a cure literally worse than the disease.  Spam now is a
hassle, but automated tools ameliorate it to a large extent for most
users.  Too many agencies at all levels of the internet would find it a
hindrance with little advantage.  So it will never be adopted.

> encryption and/or MAC using *my* PK (imposing a burden per message). 

Or it could just reject them out of hand.  Remember, the burden per
message simply cannot be scaled to where a spammer would care without
bringing the entire Internet's mail transport system to its knees.

> necessary to be an effective deterrent to abuse by strangers.

It would indeed, and that's the problem.  In order to be effective, your
MTA has to increase it to where it is as big a "deterrent" to use by
strangers as it is to abuse by strangers.

   rgb

---

From: John Leslie <[email-masked]>
Date: Thu, 26 Feb 2004 15:59:53 -0500

I strongly recommend gathering some principles of spam-abatement to
enlighten the spam BOF at IETF-59. (I'd be happy to edit such a
document, but it might be better to chose someone who will attend
IETF-59...

> effects, then occasional false positives aren't much of a problem.

   I nominate this statement for #1 on that list of principles.

--
John Leslie <[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 26 Feb 2004 14:38:28 -0800

Please note that the BoF scheduled for Korea, MARID, has a
very specific topic and that discussion of other spam-related
issues is not appropriate for that session. The BoF agenda is
available at:

http://www.ietf.org/ietf/04mar/marid.txt

To quote the salient part of the agenda:

>This BoF will be strictly limited to measures related to MTA 
>authentication; no
>other anti-spam measures or topics will be considered.  The BoF will 
>explicitly
>consider how DNS-based MTA authentication mechanisms would be implemented and
>deployed, and it will consider the impact on the overall DNS infrastructure of
>this deployment.

With best regards,
			Ted Hardie
			co-chair, MARID BoF

---

From: James Seng <[email-masked]>
Date: Fri, 27 Feb 2004 08:49:05 +0800

Can we don't pretend we can solve the spam problem on [email-masked]?

james

Iljitsch van Beijnum wrote:

> was categorized as spam back to the sender without adverse side effects, 
> then occasional false positives aren't much of a problem.
>

---

From: Ed Gerck <[email-masked]>
Date: Thu, 26 Feb 2004 22:33:15 -0800

"Robert G. Brown" wrote:
> [snip]

What? Gimme a break. I can impose the exact time burden I want at each s
step in a protocol -- I simply do not reply before the time I want elapses. 
This is SOP in any attack protection or congestion-control toolbox. There 
is NO Moore's law here.  

Work burden, when well-engineered with a time burden, can also certainly be 
added specifically  when desired and without penalizing everyone. For example, 
work burden can be demanded when a message has a non-verifiable envelope ---
it will NOT burden senders that have verifiable envelopes.

Regards,
Ed Gerck

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Feb 2004 15:29:46 +0800

John,

>> was categorized as spam back to the sender without adverse side

unfortunately, that act of communication _is_ the adverse side
effect.  it tells the spammer that yours is an active, responsive
email account.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Feb 2004 09:19:03 -0500

Dave Crocker <[email-masked]> wrote:
> [ effects, then occasional false positives aren't much of a problem.]
> 

   I must disagree.

   Iljitsch stated it precisely and well: "the fact that a message is
discarded as spam" need not give any information about whether the
recipient is an active email account -- least of all "responsive".

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Feb 2004 09:29:09 -0500

Ted Hardie <[email-masked]> wrote:
> issues is not appropriate for that session.

   While I am _very_ sympathetic to the need to limit the discussion,
I really don't see how anything useful can be accomplished if the
chair rules "principles of spam-abatement" to be irrelevant.

   Regardless, "principles of spam-abatement" don't need to be
_discussed_ at this BoF in order to "enlighten" it.

   Thus, if Ted meant to indicate such principles shouldn't be discussed
here, I respectfully disagree.

>>> If we can communicate the fact that a message is discarded because
>>> it was categorized as spam back to the sender without adverse side

---

From: Ted Hardie <[email-masked]>
Date: Fri, 27 Feb 2004 08:08:15 -0800

>chair rules "principles of spam-abatement" to be irrelevant.

Perhaps this would be clearer:  The BoF proposes that the IETF
take on a particular engineering task, with a specific scope and
an intended effect.  It is within the purview of the BoF to discuss
whether that is the right scope, whether the intended effect
is a good idea, and so on.  General discussion of the "principles
of spam-abatement" , however, is out of scope (largely because such discussions
tend to be non-terminating and will swamp the more focused engineering
discussion).  But the context of  the "is this the right scope, and a good
idea" no doubt includes the participants understandings of those principles.
			regards,
				Ted Hardie

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Feb 2004 14:48:41 -0500

> http://www.ietf.org/ietf/04mar/marid.txt

   In particular:

] Thursday, March 4 at 0900-1130
] ...
] Current Proposals (1 hour together)
]    MTAMARK - draft-stumpf-dns-mtamark-01.txt

   MTAMARK (17 pages) proposes DNS records in in-addr.arpa to indicate
that a particular IP address (or range) is or is not intended to be a
Mail-Transfer-Agent. The details of what record formats to use, IMHO,
deserve to be discussed by an IETF Working Group.

   This proposal depends on the authenticity of the in-addr.arpa
delegations; thus poorly-maintained regions of in-addr.arpa will
necessarily authorize too much or too little. Further discussion of
how to determine which regions are well-maintained will be needed,
although clearly that can be a local decision.

   I would suggest the possibility of specifying a similar mechanism
not under in-addr.arpa -- but instead under the domain records of
any domain one might wish to trust -- showing whether that region of
in-addr.arpa is considered well-maintained and trustworthy.

]    DRIP - draft-brand-drip-02.txt

   DRIP (21 pages) proposes adding A(ddress) records for named
subdomains to indicate which IP addresses are assigned to SMTP servers
authorized to send mail for that domain. This proposal gives a far
better presentation of how to implement for IPv6.

   At first blush, it seems easier to classify well-behaved domains
that well-maintained regions of in-addr.arpa; but IMHO the problems
are similar, and the implementation of DRIP within MTA software
seems more complicated.

   In any case, I would suggest a parallel specification of vouching
for the behavior of domains, under the domain records of any domain
one might choose to trust.

]    RMX - draft-danisch-dns-rr-smtp-03.txt

   RMX (35 pages) proposes adding RMX records to return various kinds
of methods to determine whether a particular SMTP sender is authorized
to send mail for particular email addresses.

   Adding new DNS record types, of course, is fatal for quick deploying.
Thus RMX also presents an alternative to accomplish this with TXT
records.

   IMHO, this scheme is even more complicated, and solves less of the
problem.

]    DMP - draft-fecyk-dmp-01.txt

   DMP (36 pages) proposes adding DMP records to identify computers
authorized to send SMTP email in the name of a domain, using TXT records
in a named subdomain.

   I'm getting bleary-eyed -- I'm no longer sure which of these proposals
is most complicated. This one, at least, appears to present complete
details sufficient to implement from.

   However, I doubt that forcing email with particular From addresses
to use a limited set of servers will be considered acceptable.

]    SPF - draft-mengwong-spf-00.txt

   SPF introduces a language for "email-related declarations" in DNS.
Messages which do not satisfy the "description" advertised are considered
"not legitimate."

   SPF specifically allows caching the DNS replies. Caching is a general
problem in DNS, in that the controls on expiring DNS information are
weak. IMHO, the weaknesses of DNS in withdrawing no-longer-valid entries
MUST be a charter item for MARID.

]    FSV - draft-levine-fsv-00.txt

   FSV (7 pages -- thanks, John!) proposes both "block" and "factored"
DNS records, as A(ddress) records under a _fsv subdomain of the "sending"
domain, returning a code for a valid SMTP sendor address.

   This, IMHO, is subject to the usual comments about end-users accepting
limits on which SMTP servers they may use.

>> The BoF will explicitly consider how DNS-based MTA authentication
>> mechanisms would be implemented and deployed, and it will consider
>> the impact on the overall DNS infrastructure of this deployment.

   In general, I predict a very boring BoF if only those who read every
page of every proposal are allowed to speak. ;^)

   IMHO, the central issue is the level of trust to be given to a
particular SMTP sender (by IP address) not well-known to the SMTP
receiver. I published my thoughts on this in

http://www.jlc.net/whitecap.html

   (Although it's obvious how to recast this into a DNS-dependent
proposal, I do not intend to do so.)

   I'd like to add a warning to limit the time you spend listening to
proposals that the speaker may describe as "the only way" to "cure the
spam problem".

   There is, however, no room for question that _some_ IETF Working
Group with a charter relating to spam-abatement is justified. I hope
those present will agree that a charter allowing discussion of all
these drafts is appropriate.

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Feb 2004 18:18:12 -0500

Dave Crocker <[email-masked]> wrote:
> 
> The difference is that there are practicalities of implementation and
> use that we have to anticipate.  This falls under the unfortunate
> reality that the real-world is not conducted so carefully.

   I have great respect for Dave's viewpoint on that issue.

   But I do think there's a principle here that doesn't depend upon the
implementation: that silently dropping a false-positive _does_ create
problems as perceived by the end users -- and that those problems would
be significantly reduced if the innocent sender of the false-positive
email were notified of the failure to deliver.

> On the average, user-level Internet mechanisms need to be pretty
> simple and straightforward, if they are to be successful.

   Omigosh yes! I've taken far too many support calls: "Is the Internet
down?" to think otherwise...

   But I, at least, am thinking in terms of an implementation where we
notify the SMTP-sending-server during the SMTP session, with a message
including a URL for more information. IMHO, this would tend to converge
to a situation where end-users understood the issue -- and learned to
route around it. ;^)

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 27 Feb 2004 16:45:31 -0700 (MST)

> From: John Leslie <[email-masked]>

> to a situation where end-users understood the issue -- and learned to

Where is the business of the main IETF mailing list in that suggestion?
It is already a de facto standard.  Many and probably most well run
SMTP servers include an appropriate message in their 5yz rejection
messages when spam detection is the issue.  Today an appropriate
message is often a URL.

There are details that could be officially standardized such as formats
that MUAs could more easily recognize and present to end users.  The
bounces generated by the near-end MTA after a failed SMTP session are
incomprehensible to many people.  Some MTAs (e.g. Hotmail's when I last
checked) include random text in their session transcripts apparently
drawn from random SMTP sessions during that last several hours.  However,
this sort of standardization seems more appropriate for some SMTP WG
or the ASRG than here.

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Feb 2004 19:34:03 -0500

> Where is the business of the main IETF mailing list in that suggestion?

   That statement -- outlining my personal thinking -- was intended to
solicit consensus on Iljitsch's principle from Dave Crocker and/or
those who think like him. (I know most people have given up on ever
finding consensus from Dave, but I'm a slow learner...)

> It is already a de facto standard. 

   (Most people, when they say "de facto standard", mean something already
done by a strong majority. But, of course, that's not what the words
mean, so I won't argue your usage.)

   I'm frankly not concerned whether that practice is endorsed as a
standard.

> Many and probably most well run SMTP servers include an appropriate
> message in their 5yz rejection messages when spam detection is the
> issue.  Today an appropriate message is often a URL.

   Agreed. Enough people are doing it that the idea will surely spread.
Even the dinosaurs (cable companies and incumbent phone companies) will
catch on eventually.

> drawn from random SMTP sessions during that last several hours.

   All items which I'd be happy to see discussed in MARID.

> However, this sort of standardization seems more appropriate for some
> SMTP WG or the ASRG than here.

   There is no MARID mailing-list yet, so we're stuck here for a few
more days. (ASRG is not an IETF group.) In the meantime, I'm trying to
solicit consensus -- no matter how "rough" -- on principles of spam
abatement, not details of its implementation.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 01 Mar 2004 06:47:06 +0900

I believe [email-masked] (usual -request convention) was intended for 
this discussion.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 28 Feb 2004 07:23:59 +0900

John,

>> effect.  it tells the spammer that yours is an active, responsive

JL>    I must disagree.

JL>    Iljitsch stated it precisely and well: "the fact that a message is
JL> discarded as spam" need not give any information about whether the
JL> recipient is an active email account -- least of all "responsive".

If this were a math exercise, I would have to agree with your point.
And even though it is not a math exercise, your point certainly is
relevant.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 28 Feb 2004 07:27:09 +0900

John,

JL>    While I am _very_ sympathetic to the need to limit the discussion,
JL> I really don't see how anything useful can be accomplished if the
JL> chair rules "principles of spam-abatement" to be irrelevant.

It is a small matter of seeking to have a productive meeting.

Discussion about the definition of spam or other broad topics, such as
principles of abatement are certainly important, but they also suffer
from a) taking a long time, and b) tending not to converge on a rough
consensus agreement.

By contract, discussion of specific techniques can be very efficient.
 This falls under the category of "I may not know much about spam, but
 I know what spam control mechanisms I like".

Yes, there are weaknesses in this approach, but they aren't as bad as
wasting an entire BOF debating philosophy.

d/

---

From: Paul Vixie <[email-masked]>
Date: 01 Mar 2004 03:57:49 +0000

> >> unfortunately, that act of communication _is_ the adverse side effect.
> >> it tells the spammer that yours is an active, responsive email account.

that's only true from the smtp perspective.  since smtp does not encode any
aspect of consent, existence implies reachability.  however, since smtp is
dead meat rotting in the sun waiting for us to figure out what to replace it
with, smtp is not relevant in a discussion of "principles" which this claims
to be.  (anyone who thinks that smtp can be upgraded to encode consent needs
to spend a few more years Just Hitting Delete before you can sit at the
grownups table.)
-- 
Paul Vixie