Subject: [Asrg] Random thought

From: Jason Hihn <[email-masked]>
Date: Wed, 12 Mar 2003 11:41:40 -0500

What if we assigned a bucket in the email address?

joe[spam]@paytimepayroll.com

Consent expression is then indicated by the bucket [spam]
So if I wanted to give a contest (to win a BMW) my email (because they
require it) my email, I'd on the fly assign BMW's email to their own bucket,
I can specify joe[bmw] when registering to win a BMW on a website.

Then, my mail client can give it it's own folder, or swash it into a default
inbox according to my rules. It can create folders as it sees email (or if
spammers abuse it, we can manually set up a folder, and trash anything not
going to that folder)

The big problem is that [bucket] can be stripped off. So solve this problem
joe@ is to be considered invalid. Some bucket must be specified.
joe[default] would be one such example(though poorly choosen) Or joe could
set his [BMW] bucket to be his default inbox in his mail client.

This will also allow us to track who sells our info. If I start getting mail
sent to the BMW bucket and not from the sponsors, I know they sold my info.
After the contest, I can trash anything automatically sent to that bucket.

This makes evading spam rather easily, while still retaining your email
server and provider.

Comments?

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Wed, 12 Mar 2003 12:25:46 -0500

Giving out personalized email addresses to all correspondents is useful
and great fun too. I do this with structured addresses @stewart.org.

The greatest entertainment happens when (a not-random example) I start
getting porn spam to "[email-masked]".  A letter to the CEO and
chairman produces all sorts of response. Sort of like poking an anthill
with a stick.

Unfortunately a lot of addresses get given out, it is not so easy to
manage them, and it is confusing for the people you really want to
talk to.

Oddly enough, too, I get much more traffic to addresses in stewart.org which
I have NOT given out.  Most are typos from some other intended domain.

This discussion leads me, in a roundabout way, to a topic about which I
am confused.  Should mail to invalid recipients be rejected or merely
discarded?  If mail senders are legitimate, then rejecting bad mail makes
sense. It helps folks who have made typos, of which I have made my share.
However for spammers, I have not heard, or perhaps not understood, the 
argument.  My own inclination is to silently accept such things as my small
part in the task of making spamming uneconomic.

-Larry

---

From: Jason Hihn <[email-masked]>
Date: Wed, 12 Mar 2003 13:18:16 -0500

Whoops. I forgot the obligatory:

Adoption:
10%: who cares? (Assuming) My server supports it (it has to for me to use
it), I can benefit right NOW using client-side filters. The sender needs to
know nothing, nor have anything special to send to me. I have immediate
benefit.
50%: ditto
90%: ditto

;-)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jason
> Hihn
> Sent: Wednesday, March 12, 2003 11:42 AM
> To: ASRG
> Subject: [Asrg] Random thought
>
>

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 12 Mar 2003 11:15:38 -0700 (MST)

> From: Jason Hihn <[email-masked]>

> ...

How does that differ from what many people have been doing that for
many years using the sendmail '+' mechanism?  The sendmail mechanism
is not a silver bullet.  I prefer to invent a new alias every time I
need to give an address to a vendor or other untrusted party.  It is
more work than the sendmail '+' mechanism, but is less easily "stripped."

Two more random throughts or rants:

Consider the RBL+, SPEWS, and SBL as models for how popular a favorite
spam defense might be after several years.  All of those are said to
have significant good effects immediately and if everyoone used any
one of them, the spam problem would be solved overnight.  They don't
require mail senders or other mail recipients to do anything.  All of
them are trivial to install.  SPEWS and the SBL are entirely free
other than quite modest per mail message bandwidth and other costs.
The monetary costs of the RBL+ are less than many proposed alternatives.
The RBL and SBL are said to have very low false positive rates.  They
are all reported to be at least 20% and according to some more than
70% effective (spam rejected divided by total spam).  In summary,
all three are exemplars of what many spam defenses would like to be.

The rub is that they've been around for years and have not been adopted
by even 50% of the Internet.  Depending on whose estimates you believe,
they're in use for between 10% and 45% of all mailboxes.

If your favorite spam solution depends on 70% of the net using it before
it is as effective as those systems, why will it do better than the
RBL+, SPEWS, or the SBL and how will it ever reach that critical mass?

I think such potential barriers are simply too high.  If a defense
depends on at least X% of the net using it to reduce your spam load
by X% for any X greater than 0.01%, then it is hopeless.  You will
not use it unless you invented it or are selling it and it will never
be adopted by X% of the net.

  ....

If you accept that potential barrier argument, is there any hope in
any mechanism that involves communicating consent?

  ....

Which is the rant, the statement that "If we switch to using my special
variety of unicorns for mail transport, the spam problem will be ended
because the unicorns will use their horns against spammers" or the
question "How will we breed enough enough unicorns?"

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 12 Mar 2003 18:18:38 +0000

> part in the task of making spamming uneconomic.

There's lots of arguments on both sides of the fence for 5xx'ing 
invalid addresses or spam. I'm beginning to think that 5xx'ing spam 
makes the spammers evolve faster (they know their open relay spam is 
being blocked so they move on to open proxies), and so I think you 
should only 5xx unknown users, and accept caught spam. But I don't 
believe you can silently junk spam either - you have to either 
quarantine it or filter it to a folder. That way if there's a false 
positive it can be retrieved, and even the sender can be notified that 
there was a temporary problem that they may need to fix (especially if 
its a blacklisting).

But I'm still not entirely 100% on the above, especially in the face of 
Striker or AOL - that's just too much spam to quarantine.

Matt.

---

From: Jason Hihn <[email-masked]>
Date: Wed, 12 Mar 2003 13:15:06 -0500

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, March 12, 2003 12:26 PM
> To: Jason Hihn
> Cc: ASRG
> Subject: Re: [Asrg] Random thought
...
> part in the task of making spamming uneconomic.

Enter domain authentication... It's be nice to know if your rejected mail
will be rejected, or sent to a spoofed address...

---

From: wayne <[email-masked]>
Date: 12 Mar 2003 13:12:46 -0600

In <[email-masked]> [email-masked] writes:

> discarded?  

I'm interested in hearing others opinions, but in my opinion, you
should reject invalid recipients as early in the process as you can.
In particular, if you can reject the email before the message has been
accepted by the receiving MTA, you force the sending MTA to do the
bounce.  This means that the receiving MTA is not responsible for
bounces that get sent to another of the spammers victims and decreases
the chance that you will be (falsely) labelled as a spammer.

If you silently accept email with invalid recipients, you may well end
up in the same position as Alan DeKok.  (see
http://www.striker.ottawa.on.ca/ and his several million spams per
day)  Spammers often have more bandwidth than you do, and often care
less about wasting it (since it is often stolen bandwidth.)  Trying to
get spammers to waste their bandwidth by consuming yours doesn't sound
like a good idea to me.

Similarly, I'm not sure that disabling the VRFY SMTP command is a good
idea.  Yes, the VRFY command can be easily used by spammers to do a
dictionary attack on your server, but if you don't let them do it the
"easy" way, they will likely do it the "hard" way by sending spam to
every possible email address.  Again, this increases your bandwidth
and if the spammer doesn't get a rejection, it may well greatly
increase your bandwidth a la stiker.

These kinds of things seem to fall into the "cutting off your nose to
spite your face" category.

-wayne

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 12 Mar 2003 16:05:56 -0500

> get spammers to waste their bandwidth by consuming yours doesn't sound

Slight correction.  Striker never did that AFAIK.  Striker always 
rejected, via either outright denial of connection or inline rejects 
rather than bouncing or accepting.  The unproven supposition is that his 
problem is because of one or two malfunctioning dictionary runs. 
There's on the order of 1500 or so unique destinations in the load.

To an example more to the point and closer to my heart: our spamtraps 
didn't even have MXes for two years.  Spam load before the MXes was 
removed was on the order of 50,000/day.  Spam load after the MXes was 
restored is on the close order of 800,000/day and growing slowly 
day-by-day.  There's about 10,000 unique addresses in the spam load.

Note: _our_ spamtrap accepts _any_ address (our spamtrap has a hardcoded 
"yes" to every question).  Your supposition would suggest that it'd grow 
far faster than it is.

I think comparing our numbers with AOL and/or MSN would suggest that 
"late bouncing" isn't anywhere near the influence as you may think.

Remember, Millions CDs are write-only.

> every possible email address.

Multiple "RCPT TO" then "QUIT" is the same as VRFY.

We don't see a lot of that on our spamtrap actually.  What we see 
_vastly_ more of is "HELO/MAIL FROM/QUIT" same "MAIL FROM" all the time. 
  God knows why they're doing that.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 12 Mar 2003 14:21:51 -0700 (MST)

> From: wayne <[email-masked]>

> every possible email address. ...

That is not the hard way to do a VRFY when the target SMTP server has
turned off VRFY.  Instead the extremely well known alternative consists
of replacing the SMTP VRFY command with two commands.  Use a Mail_From
command with any sender that you think will be acceptable to the target
followed by a Rcpt_To command with the address you wish to verify.
The result is at least as reliable as VRFY and does not require
significantly more of your bandwidth, computing, or even thinking.

If you run an SMTP server, you can watch the spammers do zillions of
these sorts of VRFY commands.  Spammers use this tactic even when VRFY
is turned on, because this mechanism cannot be turned off and it is so
easy.

Of course, EXPN is something else.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 12 Mar 2003 21:42:03 +0000 (GMT)

> all three are exemplars of what many spam defenses would like to be.

Just some figures for this, on my home system (which I admit isn't 
statistically significant, but we don't use these DNSBLs at work) the SBL 
stopped 7% of my total spam this week, wirehub (open proxies) stopped 32%, 
and monkeys.com (another open proxies list) stopped just over 1% and ORDB 
stopped 1%. I have a feeling wirehub beat monkeys.com simply on speed, and 
so looks better, but there should be no overlap with the other lists.

The rest was stopped by a combination of different content filters (and a 
few sneaked through the net). Oh, and zero false positives - these DNSBLs 
have very low false positive rates generally.

This doesn't prove much except that different people get different results 
with their DNS blacklists.

[This has nothing to do with why you posted the above I know, but people 
earlier were asking for some figures so I thought I'd post some].

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 12 Mar 2003 15:12:41 -0700 (MST)

> From: "Chris Lewis" <[email-masked]>

> Remember, Millions CDs are write-only.

Not all spam target lists are on Millions CDs.

> Multiple "RCPT TO" then "QUIT" is the same as VRFY.

Minor nit:  "Mail_From" then "Rcpt_To" is the same as VRFY.  VRFY does not
imply quit.  For a really minor nit, N VRFYs are the same as
1 Mail_From followed by N Rcpt_Tos.  Spammers often follow one or
more RCTP_To probes with a QUIT, but they don't need to.

>   God knows why they're doing that.

What's wrong with the obvious explanation, that they're validating
target lists?  The (equivalents to) VRFYs in my logs tend to be for
usernames that are valid or close to valid or to obvious dictionary
lists.  VRFYs are often followed by spam from the same spammer, judging
from various stigmata common between the VRFY and the spam.  I've done
other obvious experiments with names culled from VRFYs, and found the
obvious things you'd expect if you assume many spammers are not stupid
and understand their businesses as well as you do.

Validated target lists are sold by spammers as more valuable.
Some target MTAs penalize IP addresses with too many bad Rcpt_Tos.
Open proxies and relays are readily available, but there's no point
in burning a relay or proxy if you can buy a "verified" target list.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 17:18:21 -0500

> target lists?  The (equivalents to) VRFYs in my logs tend to be for

HELO
MAIL FROM
QUIT

No RCPT TO.

I've seen a few myself, and no idea why either.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 12:35:01 -0800 (PST)

HELO, MAIL FROM, QUIT is how spammers verify if they are blacklisted from 
that machine, at the same time they also look at SMTP greeting header to 
see which machine this is. This is also way of cleaning up their list 
preparing for spamming, they want to make sure they are allowed in and not 
blacklisted so before major event, they would verify their FROM address 
and if it is not accepted, use different domain in from for that particular
mail server or different ip address as an origin. I suspect the 2nd part 
(ip address) is more important, they are trying to subdivide large email 
list among multiple relays and want best-hit ratio.

The above is my own conclusion and I'v no real proof of this. But I think 
this helps to explain what is going on.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 12 Mar 2003 15:50:58 -0700 (MST)

> From: [email-masked]

> I've seen a few myself, and no idea why either.

Oh, I've seen those mysteries.   I thought Chris Lewis's note 
lacked RCPT_To as a typo.
Could those be efforts to check for IP address or sender domain
blacklists?  They wouldn't work for that if the target does something
like the typical sendmail "delay checks" business.

I'll raise the betting with complete SMTP transactions that land in
my traps with a body consisting of only "QUIT" and not to mailing list
control addresses but to dictionary attack names such as
[email-masked].  They're not common enough to be ordinary
VRFY efforts.

Then there are the relay attempts that consist entrely of Hipcrime
style word lists.

---

From: wayne <[email-masked]>
Date: 12 Mar 2003 17:34:56 -0600

In <[email-masked]> "Chris Lewis" <[email-masked]> writes:

> > up in the same position as Alan DeKok. 
> 
> Slight correction.  Striker never did that AFAIK.

Slight correction.  I never said that Striker did, just that you could
end up in the same position.

> Multiple "RCPT TO" then "QUIT" is the same as VRFY.

I'm sure I'm showing my ignorance here, but then, I tend to stay away
from all DJB projects.  However, it was my understanding that qmail
didn't do much validation on the RCPT TO, the validation would come
much later.

Anyway, my points were that reporting errors was important because you
want false positives to be reported and it doesn't hurt the spammer
much by not reporting errors.  Also, validating early is better
because you waste less bandwidth, and you can force the sending MTA to
do the bounce.

-wayne

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 12 Mar 2003 17:45:21 -0700 (MST)

>                   ...   However, it was my understanding that qmail

Also in common sendmail configurations, such as when you want to
excempt some recipients such as postmaster from access_DB filters.
See http://www.google.com/search?q=sendmail+delay+checks

> because you waste less bandwidth, and you can force the sending MTA to

If the sending MTA is standards compliant, you can force it to do the
bounce provided you say 5yz at any time in the transaction including
the very last bits of the transaction.

If you count bits including the DNS lookups for the IP address, HELO
value, Mail_From domain name, and Rctp_To domain names, any IDENT
checks, and DNS blacklists, you often find that the bandwidth required
to process that DATA command and receive the body is less than half
of the total.  Stopping before the DATA command is often not much of
a bandwidth savings except for worms and legitimate mail, and you can't
stop the first before the DATA command and don't want to stop at all
for the second.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:12:03 -0800 (PST)

Based on my tests less then half of mail servers will accept 500 error 
after data command (those are mostly the ones that support limits on size 
of emails - SIZE ESMTP extension I believe). The trick that has been used 
is to issue RSET command to reset the session to beginning (which is more 
widely accepted) even at DATA and then bounce with 500 or to simply 
disconnect (before end of transmission, which would cause calling email 
server to try again). But that you can't easily bounce email and filter 
during DATA transmission is very unfortunate and puts many email filters 
in the position of returning unwanted email (to FROM command, which is 
often invalid and thus wasting servers resources) instead of bouncing it 
at the transmission. 

My review of solutions shows that most would require additions to SMTP 
such that email server can not make a decision after RCPT and TO command 
and only can do it either after all headers are received or after main 
body of email is received. What I really would like is ability for 
receiving mail server to get data or parts of it (particular header, 
mime structure of the email, particular mime object) out of band before 
making final decision on accepting or rejecting entire email. 

Also I do not agree that DATA is < 1/2 of the amount of transmission for 
each email. It is true for all those small emails we often sent to each 
other (which almost all are not spam) but for larger emails that have 
larger chance of being spam or virus, DATA portion takes well over 75% of 
total packet count.

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 12 Mar 2003 21:57:42 -0500

>joe[spam]@paytimepayroll.com

I've been doing this for about a year.  (Using 
[email-masked], which is supported by many MTAs).  It 
turns out that it starts to be a pain to manage.  Companies change 
names, domains change.  You start to have addresses registered at 
sites where you aren't sure which token you used.  Never mind that 
you get the sites that don't let you type in a + in the address (or 
like drugstore.com, which just made it impossible for me to access my 
email account because they added that restriction *after* I had 
registered--not to worry they said, they'll fix it in 3-5 weeks.).

But it hasn't had any impact on my spam.  Why?  Because legitimate 
sites don't sell your email address.  And I don't give my address to 
non-legit sites.  Most of my spam comes from postings to mailing 
lists and other things that put my address on the web.  Giving each 
of those a different address would a) result in a lot of spam, b) 
make it hard to send mail to a mailing list and c) would (if I 
blocked them once I started getting spam) make it difficult for legit 
folks to get in touch with me.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 12 Mar 2003 20:16:37 -0800

On Wednesday, March 12, 2003, at 08:05  PM, Damien Morton wrote:

> Yeah - fundamentally, any spam solution has to be able to pass this
> test:
>
> Can I publish my email address anywhere and not expect to inundated 
> with
> spam.
>

Which sounds awfully like a whitelist system to me. Implementable 
today, no protocol enhancements, minimal training, and decent systems 
can be pre--programmed to minimize the hassles to people you WANT 
sending to you....

the big issue on whitelists seems to be the social issue, the "jumping 
through hoops" issue. But I haven't yet seen a suggestion I thought 
didn't require at least that much hassle/work/retraining/etc and most 
require a lot more. So why not whitelistings as part of a solution as a 
lesser evil to all this other stuff?

-- 
Chuq Von Rospach, Architech
[email-masked] -- http://www.plaidworks.com/chuqui/blog/

No! No! Dead girl, OFF the table! -- Shrek

---

From: "Damien Morton" <[email-masked]>
Date: Wed, 12 Mar 2003 23:05:30 -0500

> Behalf Of Kee Hinckley

Can I publish my email address anywhere and not expect to inundated with
spam.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 12 Mar 2003 18:27:16 -0500

> be adopted by X% of the net.

  Let's turn a problem into a solution.

  Is there a critical percentage of the net which will cause/force
wide-spread adoption of an anti-spam method?  If so, who are they, and
what percentage of the net do they control?

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 12 Mar 2003 18:34:26 -0500

"Chris Lewis" <[email-masked]> wrote:
> rather than bouncing or accepting.

  Yes.  I set up a domain, added myself as a user with email, and
waited 5 years.

>  The unproven supposition is that his problem is because of one or
> two malfunctioning dictionary runs.

  At this point, I think it's impossible to know for sure.

  But it does prove that spammers don't prune their databases.

  Alan DeKok.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 12 Mar 2003 21:45:36 -0700 (MST)

> From: [email-masked]

> of emails - SIZE ESMTP extension I believe).

I'd like to believe that you've only hit bad patch of SMTP clients.
I think sendmail has done the right thing with a 5yz response to DATA
for eons.  Many major SMTP clients that used to ignore 5yz responses
to DATA commands such as Hotmail's now do the right thing.

>                                              The trick that has been used 
> server to try again). 

Who uses that tactic?  Many of the many sendmmail Milter filters
don't but do use simple 5yz responses to Data comamnds.

>                     . But that you can't easily bounce email and filter 

I don't understand that.  If your SMTP server says 5yz to the STMP
client and incorrectly assumes that client is not junk, then it won't
know that no bouce was generated.  That no bounce is generated in this
case is no more the responsibility of the rejecting SMTP server than
any other bug that causes the other machine to fail to generate a
bounce when it should.

> making final decision on accepting or rejecting entire email. 

Again, why do that when the protocol already includes sufficient
provisions for examining headers or data before making a final decision?

What SMTP lacks is a way to say in response to the DATA command "reject
for the 1st recipeint, accept for the 2nd, and temp-fail for the 3rd."
To the DATA command ou can only say accept, reject, or temp-fail for
all recipients togehter.

---

From: "Damien Morton" <[email-masked]>
Date: Wed, 12 Mar 2003 23:44:40 -0500

> From: Chuq Von Rospach [mailto:[email-masked]] 
> 

Im not sure that the test I proposed implies any particular system,
including whitelists. My own personal preference is a sender-pays
system, implemented at the ISP level, which would be equally effective.
Im sure others have proposals that would satisfy the test.

> lesser evil to all this other stuff?

Its probably a little premature to be voting on various approaches.

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 12 Mar 2003 20:58:39 -0800

> Im sure others have proposals that would satisfy the test.

Sender pays requires a set of standards, cooperative implementation, 
some non-trivial infrastructure to make it work, and a lot of time and 
energy. Whitelisting is something that can be built on an individual, 
site or organizational level without a need of new standards, new 
protocols, financial transactions, certification, PKI infrastructures, 
or anything else. It can be implemented today, in fact, layering on top 
of what's there in most cases.

No, it doesn't solve all problems. but it solves some useful subsets of 
problems, which simplifies the issue of solving the next subset.

> Its probably a little premature to be voting on various approaches.

I'm not voting. Or suggesting we vote. I'm suggesting that, compared to 
some of the "rewrite the world" approaches, we consider more 
off-the-shelf and less, well, world-changing ones as well.

Stress is when you wake up screaming and you realize you haven't fallen 
asleep yet.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 19:56:17 -0800 (PST)

> I'd like to believe that you've only hit bad patch of SMTP clients.
Since I was testing mail servers that connected to my mail server, 
possibly the data was contaminated by spammers who just dont take no (500) 
for an answer.

> provisions for examining headers or data before making a final decision?
After you receive entire email though... Why wase so much bandwidth when 
75% of spam can be rejected based on just incorrect headers and most 
solutions require using special headers for additional information on 
authentication as well allowing to distiguish between standard mail and 
authenticated email.
 
> > But that you can't easily bounce email and filter 
I'm way confused by what you wrote. What I meant is that there is a difference 
between how blacklists work (when SMTP servers responds with 500 just based on
your ip) and how spam filters work (which scans the email, trys to 
classify it as spam and it is - its either discards it or bounced back to 
the sender or sent to special spam folder). I'd rather have filtering do 
like blacklists and either return an error (instead of discarding or 
trying to send email back) or accept it (either to spam folder or to 
normal folder).

> To the DATA command ou can only say accept, reject, or temp-fail for
I agree - this is also really really needed.

What else I'd find usefull is automated way to say that it requires 
certain type of authentication for email to be accepted (and not just that 
it requires authentication as is possible now).

-- 
William Leibzon
Elan Communications Inc. 
[email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 12 Mar 2003 23:08:07 -0700 (MST)

> possibly the data was contaminated by spammers who just dont take no (500) 

I don't understand.  How can you know that 5yz responses to DATA are
ignored?  How can you tell the difference between a broken client
that ignores 5yz for DATA and a good client that generates a bounce?
The won't-take-no(5yz) STMP clients clearly do accept and recognize
5yz errors to the DATA command; they just do the wrong thing.

> authentication as well allowing to distiguish between standard mail and 

The bandwidth required to handle a single mail message is trivial.  It's
typically about that required for a single HTTP page hit.  Only if your
system is handling more than about 200,000 mail messages/day do you need
more than current puny, commodity PC hardware.  I think there are
subscribers to this mailing list who are dealing with 2 Mmsgs/day or
more with cheap, commodity PC boxes, albeit more than one box.

> the sender or sent to special spam folder).

I don't like that distinction for several reasons.  I think a "filter"
is any of those things.  Besides, there are spam defenses that use
DNS IP blacklists to detect and report spam to a distributed network
so that substantially identical copies can be rejected from unlisted
IP addresses.  DNS IP blacklists can do anything of the things that
the other sort can do, including only tag or segregate spam.  It is
at least as common for DNS IP blacklists to operate at the end of the
envelope, so that the SMTP server can accept mail to some mailboxes
such as postmaster from blacklisted IP addresses.

>                                             I'd rather have filtering do 

Some implementations of what you call "filtering" can do that.

> it requires authentication as is possible now).

It's often easier to require the authenticating tokens at the start,
do much of the processing, and only just before doing something
permanent or expensive check the authentiation tokens as well as decide
whether the request is authorized given the authentication.

In other words, if that's what you want, you could simply use SMTP-AUTH
but lie about whether you like the tokens.

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 13 Mar 2003 09:20:06 +0000

> the chance that you will be (falsely) labelled as a spammer.

I agree, it's what we try to do here. The exposure to a "dictionary attack"
may be over-emphasised. Such an attack has a pretty clear signature 
( high  invalid/valid ratio over a short time originating at  
a single IP or small range). It's possible to (dynamically) modify 
policy with respect to a source which has given that signature.

Of course, this signature is strong for us - as our ~100k accounts cover
only
a small part of dictionary (or randomised localpart) space.  
It's likely not as strong for Yahoo or Hotmail.

On a related point: We've had a number of complaints from foreign system
admins
about such attacks using a (forged) sender in one of our domains. They tend
to
send us yards of their MTA logs as "evidence". It seems that there are many
"postmasters" out there who don't know how to read their own logs 
("it's the IP stoopid!"). Sender forgery tends to come as a terrible
surprise
to them.

---

From: Daniel Feenberg <[email-masked]>
Date: Thu, 13 Mar 2003 07:14:02 -0500 (EST)

> of emails - SIZE ESMTP extension I believe). The trick that has been used 

Can you clarify?

Do you mean that many receiving MTAs don't support rejection of messages
based on content, or that if the receiving MTA rejects during the DATA
command the sending MTA will not "accept" the 500 error?

In the former case, it is easy enough for those wanting to improve their
content based scanning procedure to get an improved MTA. They are already
making a substantial change to their system.

If the latter, what happens to the message? Is it dropped on the floor?
Does the receiving MTA get some acknowledgment that the the error has not
been accepted? Can you provide MTA names? Do the offenders include any of
Exchange, Postfix, qmail? 

Finally, does this mean that MILTER based content scanning will lose mail
coming from certain other MTAs, rather than rejecting it?

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 13 Mar 2003 10:14:16 -0500

>what percentage of the net do they control?

Commercial bulk mailers have an incentive to change their systems out 
of fear of being blocked.

ISPs have an incentive to block spam if it can be done in a way that 
decreases support and maintenance costs.  In other words, adding 
complex systems isn't necessarily helpful.  Reducing forgeries so 
that they don't get fake complaints might be helpful.  Reducing 
bounces would be helpful.

For another view on who is interested in the problem, consider the 
attendee list to JampSpam.

http://www.jamspam.org/home/Participants
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 13 Mar 2003 10:09:20 -0500

At 8:16 PM -0800 3/12/03, Chuq Von Rospach wrote:
>today, no protocol enhancements, minimal training, and decent 
>systems can be pre--programmed to minimize the hassles to people you 
>WANT sending to you....
>
>the big issue on whitelists seems to be the social issue, the 
>"jumping through hoops" issue. But I haven't yet seen a suggestion I 
>thought didn't require at least that much hassle/work/retraining/etc 
>and most require a lot more. So why not whitelistings as part of a 
>solution as a lesser evil to all this other stuff?

Whitelisting works well for people who use mail for social 
communication.  They have a limited set of people they communicate 
with regularly.  My only real issue with it in that context is that 
it's a virus-writer's dream--lots of addresses to send viruses to, 
and they'll all work.  But that's really a different problem.

Whitelisting doesn't work at all for inbound company email.  I 
regularly get email addressed to me from people that I don't know and 
have never heard of before.  There are people on this list who are 
using challenge-response whitelists, and the complaints have been 
pretty loud.

However to be a true spam deterrent, whitelisting needs to do two other things.

1. It needs to *block* non-whitelisted email.  Anything that just 
puts them in a junk folder isn't a long term solution because you 
still have to read the spam every day.  It's a helpful tool, just as 
any filtering tool is--but it's not a solution, and it won't stop the 
spammers.  If it blocks the email, then you're back to the question 
of how you get past it.  Challenge response?  Assume that anyone who 
tries again is okay?  And how you deal with commercial mail systems 
that either don't read bounces, assume that the bounce is fatal, or 
don't have a system for retrying.  So you need some kind of standard 
there.

2. It needs authentication.  Otherwise the spammers just start 
forging email more than they already do.  This is a weaker need, 
because it more clearly puts spam on the illegal side of the fence, 
and greatly reduces the chance that legit companies will spam.

P.S.  Note that I'm changing the subject line.  People have 
complained about wading through the volume, so I am hoping it will be 
helpful if people are more aggressive than usual about changing 
subjects to reflect the specific content of the message when the 
thread topic forks.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Jason Hihn <[email-masked]>
Date: Thu, 13 Mar 2003 10:01:05 -0500

> Damien Morton
> Sent: Wednesday, March 12, 2003 11:06 PM
> To: 'Kee Hinckley'; 'ASRG'
> Subject: RE: [Asrg] Random thought
...
> Can I publish my email address anywhere and not expect to inundated with
Well then do this:
1) we'll leave a 'calling card' (that looks like an email address for
scripts that check for validity) when we use mail and BBS's
([email-masked]) (It can be a current email address eventually, but
bare with me here...)

2) In order to send a message to me, I must approve you. This is done by
sending me your email address (and maybe a short message). I will then give
you an encoded address to use to send mail to me. The encoded address will
use an algorithm and values of my random choosing. The encoded address will
take into account your email address and my email address.

3) You can send to the encoded address where my server will apply the from:
address to the destination address, revealing your address (mailbox) for the
mail to be deposited in.

What we have here now is a way for one-to-one verification. It works well
for ICQ AIM and the rest of the services that are pretty much junk free (ICQ
screwed some stuff up early on, but I'd not mind spam email at the frequency
of ICQ junk - 3 a month and I have a 7 digit number.)

Your hashed ID can be sold, but we still have some accountability because
the From address must remain the same for the hash to hash to your mailbox.

Once verified the user can store the hashed address in their address book.
It was still easy to give out how to get in touch with me for business cards
and the like. (We can now illustratively change back from
[email-masked] to [email-masked] since you've followed me through the
example - I hope it didn't make it more complicated to follow)

If implemented today, we'd get flooded with spam requests for IDs. No one
would answer them unless a victim of social engineering. Spam would stop
after a flood of requests. The only spam to remain is resold hashes and
from: addresses which are filterable.

Comments?

---

From: "Damien Morton" <[email-masked]>
Date: Thu, 13 Mar 2003 11:01:05 -0500

> From: Jason Hihn [mailto:[email-masked]] 
> 
> > with spam.
> 1) we'll leave a 'calling card' (that looks like an email 
> address for scripts that check for validity) when we use mail 
> and BBS's
> ([email-masked]) (It can be a current email address 
> eventually, but bare with me here...)
> 
> 2) In order to send a message to me, I must approve you. This 
> is done by sending me your email address (and maybe a short 
> message). I will then give you an encoded address to use to 
> send mail to me. The encoded address will use an algorithm 
> and values of my random choosing. The encoded address will 

Too much trouble for me. I want to publish my email address the same way
I can publish my phone number. I _want_ individual strangers to be able
to reach me without having to jump through hurdles. Im lazy, and keeping
a whitelist is too much trouble for me, especially for my publically
available email address. I don't want spam, however.

> 3) You can send to the encoded address where my server will 
> apply the from: address to the destination address, revealing 
> your address (mailbox) for the mail to be deposited in.
> 
> What we have here now is a way for one-to-one verification. 
> It works well for ICQ AIM and the rest of the services that 
> are pretty much junk free (ICQ screwed some stuff up early 
> on, but I'd not mind spam email at the frequency of ICQ junk 
> - 3 a month and I have a 7 digit number.)
> 
> Your hashed ID can be sold, but we still have some 
> accountability because the From address must remain the same 
> for the hash to hash to your mailbox.
> 
> Once verified the user can store the hashed address in their 
> address book. It was still easy to give out how to get in 
> touch with me for business cards and the like. (We can now 
> illustratively change back from [email-masked] to 
> [email-masked] since you've followed me through the example 
> - I hope it didn't make it more complicated to follow)
> 
> If implemented today, we'd get flooded with spam requests for 
> IDs. No one would answer them unless a victim of social 
> engineering. Spam would stop after a flood of requests. The 
> only spam to remain is resold hashes and

Try explaining your system my 70-year old uncle who still keeps all of
his documents on his mac os desktop because folders are too complicated.
He'll just give up. Its too complicated for 99% of users of email.

Sender-pays, on the other hand, could be completely invisible to the
user, if implemented as a trading arrangement between ISPs. Think of it
like carbon-rights trading, but for email.

---

From: Jason Hihn <[email-masked]>
Date: Thu, 13 Mar 2003 11:35:50 -0500

> From: Damien Morton [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 11:01 AM
> To: 'Jason Hihn'; 'Kee Hinckley'; 'ASRG'
> Subject: RE: Proxy your address (Was: Random thought)

....

> He'll just give up. Its too complicated for 99% of users of email.

Too complicated to say that you get to approve of who gets to talk to you,
and you have to ask someone to approve to talk to them?

And it only has to be done once per person.

I'd like to be able to have this control. Maybe something to put on a wish
list.

> like carbon-rights trading, but for email.

I think Sender-pays would go a long way, but like everything suggested to
date, not 100%.

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 13 Mar 2003 13:44:02 -0500

>and you have to ask someone to approve to talk to them?

Well, there's the little matter of the software he has to install to 
manage all these fake addresses.  But no, the complication I assume 
Damien was referring to was on the other side.  You've made it too 
complicated to talk to someone.

I get mail from random strangers that goes:  "I liked that article 
you wrote."  Do you really think they are going to jump through all 
of these hoops in order to send me that?

What about the guy who says, "I just tried xxx you wrote, and there's 
the bug where it does such and such--here's a fix."

Challenge response systems are extremely annoying to people who are 
trying to talk to you.  They are so annoying that there is no way a 
company would use them on contact email addresses.  And as an 
individual I wouldn't get lots of messages I'd really like to get.

Ironically, there is one class of people who will wade through a 
challenge response system.  The people who really want to sell me 
something.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Jason Hihn <[email-masked]>
Date: Thu, 13 Mar 2003 15:03:58 -0500

Yeah, I get emails like these too. It would be a lot of work for such a
disposable conversation.

Maybe we should devise a list of spam reducing technology and prioritize it.
My list would read:
0) Receiver Anoniminity
1) Sender verification (see note below)

Note: This should be considered different from a simple RCPT-TO check. While
easily implemented as such, it can be used to validate an address (violating
#0) IMHO RCPT-TO should not ever return an error until after the socket is
closed. Then when it goes to return an unknown mailbox error, it ends up
doing a verify of the From address. This does several things. 1) It will
prevent unnecessary error messages being sent back to a no-good address. 2)
It will slow/prevent address receiver verification.

While on the subject of recipient verification, can we do something about
embedded images in html messages? For the un-initiated: A spammer can assign
a picture (even a 1x1 transparent pixel picture) to a message. Using the
<IMG SRC="foo.php?a=[email-masked]"> he can cause your client to load that
image. But that image is a script that quietly submits (and therefore)
verifies your email address before it sends out the image. Can we come up
with a standard that requires all images (any binary content really) to be
embedded? My preferred email client has a check box to "not load remote
images in mail", which works for me, but I fret over people whose clients
aren't so careful.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Kee
> Hinckley
> Sent: Thursday, March 13, 2003 1:44 PM
> To: Jason Hihn
> Cc: Damien Morton; 'ASRG'
> Subject: [Asrg] RE: Proxy your address (Was: Random thought)
>
>
...

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 13 Mar 2003 16:05:02 -0500

>images in mail", which works for me, but I fret over people whose clients

I read somewhere that the next version of Outlook was going to ship 
with that checkbox on by default.  On the downside, that means that 
companies will be sending you larger email messages.  Can't win that 
one.

In any case, email content is definitely out of the scope of this 
group.  (Which ought to rule out content filtering :-).
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: [email-masked]
Date: Thu, 13 Mar 2003 16:12:53 -0500

> It will slow/prevent address receiver verification.

So.. instead of giving them a '550 Piss Off' right then and there, you
go to all the effort of queueing it to disk and verifying the From:
afterwards, and then finding out that you can't double-bounce.  Really
bad if you're being spammed by 100K things in a dictionary attack...

And this is a messy situation - you have to be able to distinguish between
double-bounces that should go to the postmaster because there's a real
problem, and spammer double bounces.  Silently dropping all double
bounces is a bad idea...

> images in mail", which works for me, but I fret over people whose clients

Let's note a few things:

1) This is (as you noted) really an MUA issue.

2) There's often legitimate uses for it.  If you're at the end of a slow
link, you may very well want to download your mail w/o images, and then
select 'load images' for certain pieces of mail and not others.

3) The same spammers that don't follow RFC822 won't follow your proposed
standard either.

4) Identify the major software vendors who have issues in this area, and ask
whether they're likely to implement such a standard.

5) Making it a standard won't make people upgrade.  Only user education or
forcing an upgrade on them will do that.

---

From: Jason Hihn <[email-masked]>
Date: Thu, 13 Mar 2003 16:21:26 -0500

Bah, I give up.

Looks like I'll be relying on the Bayesian spam filtering in the
just-released-today Mozilla (v1.3). So much for reclaiming band width, I'll
just route spam to /dev/null because the client makers are much more willing
to take a stab at the problem than the server admins (who ironically are
suffering more).

You (We) all are never going to make any progress at this rate. No one wants
to adopt anything. No one wants to do anything more than bitch about it. It
must not be a big enough problem then.

You're going to have to make a commitment to SOMETHING SOMETIME. Jesus,
anything is better than what we have now. If you don't want to commit to
something then stop bitching and lay in the bed you made.

I think sender verification should be started. It is easily implemented and
we can stand to have significant gains rather easily. Even if we want to use
the RCPT-TO hack in the short term.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 4:13 PM
> To: Jason Hihn
> Cc: 'ASRG'
> Subject: Re: [Asrg] Taking a step back (Was: Proxy your address)
>
>

---

From: Jim Youll <[email-masked]>
Date: Thu, 13 Mar 2003 16:45:28 -0500

I believe there has been far too much discussion generally, without 
reflection and thought... and far too much has been said about 
specific applications.

The emphasis here should be on creating guiding principles... simple, 
clear, brief guiding principles... not code nor zealous defenses of 
unmeasured techniques.

Unwanted e-mail is an old problem. I see no reason that there should 
be an agreed upon solution in a week's time. I've been involved in 
the "spam problem" since Canter&Siegel and have tried to be work in 
other groups like this on, every one of which degenerated into 
application wars and semantic battles about "what is spam" and so on.

What is missing is the guiding principles, the catalog of approaches, 
carefully considered and then summarized discussion of each, and 
empirical evidence pro and con... Everyone may not agree on what 
those principles should be, but they are probably collectively 
tree-shaped and as they fork, individuals of varied opinions could at 
least determine where they stand in their beliefs and with whom, but 
would then be expected to defend those beliefs with some hard 
evidence - applications and the results of real testing and analysis.

The problem is not "spam" - someone in this mess of noise wrote a 
very good definition of what the problem is. For me, I fall back to a 
phrase from the US Supreme Court and picked up by privacy advocates: 
"The right to be left alone."

An opinion of whether some message is or is not "spam" may very from 
person to person, and individual tolerance levels may vary, thus an 
individualized solution is needed.

Yet some things, particularly high-volume, error-packed mail blasts, 
may be "spam" in the eyes of an ISP due to their impact on networks, 
thus a server-based solution is needed.

And clients and servers may only have incomplete information, so 
client-server collaborative approaches may be needed.

And some "spam" is only detectable via a worldview that no single 
server can have on its own, thus interop between servers/ISPs may be 
needed.

Will one "agreement" solve all of this? No. But neither will more 
headstrong efforts to just dive in and start writing code. The 
problem tangles social, political, economic, historical and 
technological matters. We will not fix it by jumping in and writing 
applications, nor by trying to yell the loudest.

- Jim

---

From: Jason Hihn <[email-masked]>
Date: Thu, 13 Mar 2003 17:08:27 -0500

A very well written and accurate piece.

I like the idea of consolidating theories and proposals and the pros and
cons.

Though as a developer, I don't share in your view that we shouldn't jump in
and just start coding. I think talk is cheap and action is actually worth
something. (Though, I don't think it needs to be said that the coding effort
should be haphazard and wasted)

What I would like to see is an implementation test bed, where we all develop
and try to be spammers and  break each other's implementations. A place
where we can turn theory into fact.

You are right that one agreement won't solve it. But we have yet to agree on
any one thing. I can't get everyone to agree that sender verification should
be required. I see it as a no-brainer, fundamental starting point. I (and I
think everyone else does too) want to be left alone from senders that don't
exist.

Ultimately, I think the network should guarantee that what we get is a
'valid' (yes, yet to be formally defined) communication. Once delivered, the
user will ultimately be responsible for determining it's spammness (client
filters).

> From: Jim Youll [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 4:45 PM
> To: Jason Hihn; [email-masked]
> Cc: 'ASRG'
> Subject: RE: [Asrg] Too much of too little (Was: Taking a step back)
>
>

---

From: Scott A Crosby <[email-masked]>
Date: 14 Mar 2003 20:52:12 -0600

On Thu, 13 Mar 2003 10:09:20 -0500, Kee Hinckley <[email-masked]> writes:

> 1. It needs to *block* non-whitelisted email.  Anything that just puts
> them in a junk folder isn't a long term solution because you still
> have to read the spam every day.  It's a helpful tool, just as any
> filtering tool is--but it's not a solution, and it won't stop the
> spammers.  If it blocks the email, then you're back to the question of
> how you get past it.  Challenge response?  Assume that anyone who
> 2. It needs authentication.  Otherwise the spammers just start forging
> email more than they already do.  This is a weaker need, because it
> more clearly puts spam on the illegal side of the fence, and greatly
> reduces the chance that legit companies will spam.
> 

And a third thing:

It must not be possible to automate the whitelisting service. If
there's a way I can be whitelisted through, say a challenge&response,
then thats good for a user, I can program a robot to do it for me,
secondly, and much more problematic, if its automatable, it will be
automated and someone else will eventually write a program to
auto-reply. Although, CAPTCHA could make this work. CAPTCHA (carnegie
mellon) is an idea to have an automated challenge that a computer can
give to a human, but only humans can correctly reply; a machine
cannot. Its done currently on Yahoo, its that swirly text image thats
designed to be difficult to OCR.

Perhaps thats a key idea: What makes unsolicited commercial email
possible is because of extreme automation. If we can de-automate the
sending of email, we win. A computer is cheap; for $30k, which is one
worker for one year, we can put in 100GHZ of computing power. Human
labor is not cheap. If something requires a sender to be forced to
spend 3 seconds of their time, thats 8k email/worker/day, tops.

Hash-cash doesn't de-automate email sending, it just slows it down a little.

How about something like a CAPTCHA-stamp, where you 'prove' to a
trusted machine that you are a human, then you get a stamp that you
may attach to email. Some policy on how many times a stamp you may
reuse, or how many stamps you recieve. And, at any time, a stamp may
be checked to see if its been used too many times and the email
rejected.

How else may we slightly de-automate email sending? 

Scott

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 14 Mar 2003 23:00:27 -0500

>designed to be difficult to OCR.

As I pointed out on some earlier threads.  This needs to be both 
visual and aural if you want to pass accessibly standards.  Doable 
(and done in some cases).  Just keep it in mind.

I have heard from one person, who says he read it in Wired, and found 
one online mention 
(http://www.cbsnews.com/stories/2002/12/26/tech/main534348.shtml) 
claiming that some spammers have set up "free porn" sites that 
occasionally prompt the user to enter a value on a CAPTCHA-style 
image snarfed from a webmail site.  This is sort of the borg approach 
to distributed computing.

I'd love to see a real reference to this.  But certainly it seems 
like a viable countermeasure.

In the end, every system has a weakness.  Either in terms of 
deployment, the social cost of using it, or the ability to work 
around it if you are clever enough.  As someone else has pointed out 
on this list--dealing with spam is really like dealing with security. 
It's not going to be a on/off thing.  It's going to be a question of 
how much pain you are willing to put up with in order to gain a 
certain amount of benefit.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society