Subject: digital signature request

From: [email-masked]
Date: Wed, 25 Feb 2004 02:50:47 -0800

this is a request for this list to be digitally
signed by the list processor.

to all list members.  if after reading this post
you would like the list processor to digitally
sign all posts please say so (and tell the list
owner) so that the level of interest can be
gauged.  thanks.

i'm making this request because i need a way to
positively id the messages from this list.  i'm
spending way too much of my time culling spam from
my real email even though i'm employing the latest
spam filtering tools.  please give me the one
simple tool i know of that will allow me to
positively differentiate the mail from this list
from all others - a digital signature.

signing all list messages won't be detrimental to
list recipients not interested.  it will however
allow folks wishing to implement anti-spam
measures around digital signatures to do so.
mailing lists often require that recipients
confirm their email address as an anti-spam
measure for the list.  please help list recipients
implement their own anti-spam measures by allowing
the list messages to be positively identified.

to be clear, this is a limited scope spam
solution, but it works.  and it will continue to
work provided the underlying cryptography is sound
(unlike many other anti-spam technologies that are
simply clever hacks in an escalating spam/anti-
spam arms race).

some folks say that there will be no spam solution
as long as email is free.  i say there will be no
spam solution as long as you expect anyone to be
able to send email to you without first proving
they are not a spammer.

part of finding a solution is to revision what
email is.  i argue that email can no longer be a
method of unfettered *initial* contact.  once that
is accepted then this solution doesn't seem
painful.  i suspect that there won't be a solution
until email is seen from this perspective.  as
noted above, mailing lists are essentially
adopting this perspective (to better manage spam
on the list side), it would be helpful if they
took an additional small step that would enable
list recipients to better manage spam on their end
too.

there's no need for a larger web of trust other
than one that is personally maintained when using
digital signatures to defend against the onslaught
of spam.  your personal web of trust (a.k.a. your
keyring) is your unspoofable anti-spam whitelist.
this is where the revisioning of email occurs.
instead of email being the way you initially make
contact with an entity, with digital signatures it
can serve as a reliable communications channel
*once* contact has been established.

my intention is to implement a procmail recipe at
the mail server level.  the procmail recipe will
be used to check incoming mail for whitelisted
digital signatures that have been uploaded from
each individual user.

mailing lists could use the same recipe, no
messages would be handed over to the listserv
software unless it was signed by a whitelisted
signature.  again, this won't stop machines from
being compromised but as soon as a machine is
compromised that entity will be *immediately*
notified by their peers.  in the case of a mailing
list *many* people will suddenly know who's
compromised and the list can even have a mechanism
that allows a whitelisted key to be removed once
it becomes compromised.  this would also serve the
dual function of indirectly alerting the owner of
the compromised host since they will investigate
why they are no longer receiving list traffic.

regarding whether to utilize inline or mime GPG, i
say use either.  the preferred solution will self-
select over time.  it is possible to create a
procmail recipe that can handle both methods.

Two key benefits of this anti-spam technology:

1.  it works and will likely continue to work
beyond the foreseeable future

2.  it can be implemented without the consensus,
from the bottom up

below are my responses to posts in a few mailing
list threads regarding digital signatures and
spam.  please read my responses as they will
likely answer many of the questions that may
result from reading what i wrote above.  apologies
to the folks whose comments i'm replying to for
not referencing their names (i didn't have the
time).

looking forward to feedback.

ciao,

david
--
spam is something we can eliminate by
changing our personal behaviors and expectations
and cooperating.  and it can happen gradually.

thread:  ietf - proposal for built-in spam burden
& email privacy protection -----

>>2. Except for senders in a whitelist (e.g.,
>>list mail), I bounce to  the sender  any email
>>that is NOT encrypted with my public-key,
>>providing my   public-key and instructions for the
>>sender to resubmit the message  properly
>>encrypted.
>
>Anything at all that generates a bounce message
>on a mass-produced mailing acts as a "damage
>amplifier" from the basic internet backbone's
>point of view -- at least doubling the associated
>automated traffic and wasted/misused resources.
>These days such a bounce is especially fruitless,
>as all viruses and quite a lot of SPAM have forged
>headers that the stupid bounce agents cannot or do
>not parse.
>
>This is pet peeve of mine as it is -- I got (and
>continue to get) more bounce messages from mydoom
>reporting that mail "from me" is contaminated than
>I do copies of the virus itself.  No virus for two
>years now hasn't forged mail headers -- the From
>field is totally irrelevant in all current viruses-
>- yet all the AV programs in the world think they
>are doing you a favor. NOT.
>
>Now imagine that sort of stupidity scaled out so
>that every MTA in the world is checking esigs and
>bouncing improperly signed mail.  Imagine the
>loops created when a legacy mailer or improperly
>configured mailer bounces the bounce messages back
>to the bouncer, to be bounced again. Nightmarish.

solution - don't auto-respond, give out a keyword
with your email address, this will allow initial
contact to be more easily plucked from the sea of
spam - in the long run as more people digitally
sign email spam will become even less profitable
because there will be even fewer responses - we'll
never know what's possible if we don't try

>encrypting for each of the list recipients is too
>much of a burden for the list

solution - don't encrypt, only digitally sign -
not a burden

>Don't get me wrong: encouraging people to use pgp
>is a good idea, but making it a requirement before
>accepting it is a policy decision that the end
>user should be making, not the list.

solution - by only digitally signing it is
completely up to the end user to decide whether or
not to add this tool to their anti-spam toolbox

>Your proposal is in line with some existing ones,
>at least one of which response to the seriously
>problematic key management issue.

solution - non-local, centralized key management
is a huge problem, but key management isn't a
problem if the only important keys are your
personal ones and if you don't expect to be able
to instantaneously have access to anyone's public
key via a keyserver - keyservers aren't necessary
for folks who exchange email with primarily a
small group of people

>I'm not saying to reject non esig mails, but to
>held them for approval by moderators... If you
>want your post to go through quickly, sign it...
>It would be a worthwhile incentive.

sounds like a great idea, but this is in addition
to and isn't required for what i'm suggesting

>Also note, there is an addition burden placed on
>end users who rely on receiving encrypted email in
>your proposal.  Under your scheme, a user has to
>go through the trouble of decrypting the message
>just to see if it is spam or not.  This eliminates
>almost all forms of automated spam mitigation
>except those related to the low-level SMTP, DNS or
>other new authentication/authorization techniques.

reminds me that signing and not encrypting still
allows bayesian filters to continue to be useful

>Unfortunately, requiring that they have a
>published public-key *is* a burden to the average
>user.  J. Random Luser just wants to sit down at
>his PC, boot up Winders, bring out Lookout, and
>forward a garish HTMLified email full of stale
>jokes to his buddies, complete with pictures, and
>he wants it to go through, without a hitch, right
>now.  He thinks public keys are the ones hanging
>on the gas station wall, for the bathroom.  He
>thinks crypto is someone from Superman's home
>planet.  He thinks the IETF is them guys whut
>raided David Koresh.  He has no clue what the ASRG
>is, but he thinks it sounds dirty.

again, no need for keyservers for folks that are
exchanging email within a small group of people.
also, let's stop trying to allow email to continue
to be what it has evolved into, let those folks
that want email to stay the way it is keep it that
way, let's create a spam-free email environment
that works and satisfies *us*, i suspect that if
this is witnessed folks will eventually start
thinking of email differently as their personal
spam pain tolerances are exceeded.

>Make it worth their while, by coming up with
>infrastructure such that they won't get any spam
>if they have a public key, and MAYBE they'll
>bother doing it, IF the ISP will hold their hands
>every step of the way (and not charge them too
>much, including for issuing new keypairs when they
>let the private ones slip out too much).  Of
>course, this means that all their equally
>technically-enlightened friends have to know how
>to USE his public key....

solution - accept that it will be a gradual
process, let's just start with mailing lists
signing all messages that get sent to list
recipients - that's easy

>This sounds very much like the use of extra
>headerz, or a password on the subject line, but on
>steroids.  In the end, possibly useful, IF you can
>get everybody aboard, but they won't go until
>everybody ELSE is already on board, and meanwhile
>it's a pain in the proverbial posterior to
>everyone who wants to communicate with the people
>using it.

for me it is *less* pain than what i'm
experiencing dealing with my current spam load,
and digital signatures can be ignored if you don't
want to verify them - also, if someone tells you
that they are receiving so much spam that you will
have to sign all email you send to them, are you
going to tell them they are causing you too much
pain?  heck, just pick the phone up and call them
then.

>Second, even if the above weren't a problem, one
>still has the problem that a virus infected user
>will still be sending messages, just like everyone
>else.

this will still be a problem but with a digital
signature solution in place infected computers
will be identifiable and probably immediately
disinfected, folks will become hyper-aware of
allowing their machines to become compromised if
suddenly they are unable to exchange email with
their small and *important* group of people
because their public key became blacklisted by
these same folks - the very nature of digital
signatures positively identifies infected
computers

>There is no scheme in which the rules can't be
>broken by someone intent on breaking them.  The
>only path is to detect them, and prosecute them.
>In the case of spam, detection is easy, but not
>automatic.  Prosecution is now possible.  Its
>still a whack-a-mole game. It won't end unless you
>can get past the virus infection to the virus
>operator, and hopefully, there aren't really too
>many virus operators.  Of course, we aren't
>stopping spam either in a very real sense, but
>rather abusers who are annoying and mailbombing
>people.  But by my count of my inbox, if you stop
>those people, I can certainly handle the rest
>which amounts to maybe 1% of my current junk mail.

there's no known way to crack GPG, widespread
adoption of digital signatures against spam will
either help bring spam to and end or tell us what
NSA might already know  ;)  - let's put those
spammers to work!  also, prosecutions by a central
authority won't be necessary, peers will do the
prosecuting by rejecting email from compromised
systems, the owner of the infected system will be
de facto "punished" because communications with
their peers will end until they clean their system
(or stop spamming).

>>The "for pay" idea is just another scam from
>>the people who would love to get a percentage of
>>the pay. While I'm sure Microsoft and others would
>>just love to get a cut of this (I know I would),
>>it doesn't do anything to stop spam, and if
>>implemented, would simply (and wrongly) charge
>>users whose computers were virus infected.
>
>Wrongly?  I'm not so sure.  Something ought to be
>done to stop the  Typhoid Marys of the Internet.
>Putting them on notice that they WILL be held
>responsible for spreading the infection, or its
>effects, just MIGHT result in them FINALLY taking
>some responsibility for their "computer hygiene".
>Sure, there will have to be several well
>publicized example cases before most folk will sit
>up and take notice, but in the long run, it might
>be effective.

i agree, trying to impose a burden
(computationally or monetarily) on spammers will
not work IMHO.  i will leave it to others to
explain this in more detail.  and to repeat,
prosecutions by a central authority won't be
necessary, peers will do the prosecuting by
rejecting email from compromised systems, the
owner of the infected system will be de facto
"punished" because communications with their peers
will end until they clean their system (or stop
spamming).

>So even discussing adding a silly thing like
>mandatory esigs and encryption as an antispam
>measure is a waste of time, except possibly on a
>local basis.  If I set up a small mailing list (or
>generalized group of individuals) and all of its
>members agree to do this, there is little
>"evolutionary pressure" for spammers to detect and
>foil our scheme and we will be "immune" (at the
>cost of a fair amount of extra work).  If
>everybody does it and the automated tools for
>doing it without so much work are widely
>disbursed, they will develop countermeasures in no
>time at all and we'll lose our immunity.

please explain how spammers will evolve past the
public key encryption technology used in digital
signatures?  as noted earlier machine compromises
will still occur but they will be able to be dealt
with because peers of the compromised machine will
immediately identify and neutralize the problem by
ending communication (by blacklisting the
compromised key).  suddenly the owner of the
compromised machine hears silence.

>Automated text analysis will never be perfect,
>because even human text analysis for
>interest/disinterest (secretaries) aren't perfect.
>But it can help sort things.  I hand filter about
>1500 messages a day.  I get about 3500 over the
>weekend. Monday's filtering doesn't take me any
>longer than tuesdays filtering.

unfortunately the approach you describe could
likely be your undoing in the long run as spammers
ratchet up the volume to the point were it *will*
take you a long time using this approach.  this is
why even with 99.9% accurate bayesian filtering,
all spammers need to do is ratchet up the volume
to get more spam through the 0.1% error rate of
the bayesian filter.

>>>Then using the IETF list as an example, you
>>>would need the entire list of recipients and their
>>>public keys, and you would need to send a message
>>>either directly to each of them, one by one, or
>>>send a single message with a session key for each
>>>recipient (thousands).  This isn't going to work.
>>
>>Let's not mix apples with speedboats. These are
>>some options with the proposal:
>>
>>#1: no encryption is used either way, the list
>>address is in a whitelist for each recipient.
>>
>>#2: each recipient can only send encrypted msgs
>>(possibly, also signed) to the list, with the
>>list's key, for distribution. The listserver
>>verifies and resends the messages in plain text,
>>where #1 applies for each recipient.
>>
>>#3: the list receives messages as in #2 but the
>>listserver sends the msgs as encrypted mail to
>>each recipient, with each recipient's key.
>
>#4 (my preferred) the member send a message to
>the list with his digital signature. The list
>checks the digital signature (from keyserver or
>from a member database) and post the message if
>signature is valid. If the signature is not valid,
>the message is held for approval. But yes this
>scheme does not offer much more than restrict
>posting to list members only, which the IETF had
>to do last year(?).

if the list server signs each message that then
allows recipients to positively identify mail from
the list.  this is *HUGE*.  if i have an email
account that only receives mail from mailing lists
that sign all messages then i can dump all
incoming non-whitelisted digitally signed email at
the server and *know* that all my email is legit.

thread:  ietf - how not to filter spam -----

>>first, there is an increasingly heated debate
>>between folks who want to sign the message (TEOS,
>>DomainKeys), versus others who want to secure the
>>channel between sender and receiver (RMX, LMAP,
>>SPF, etc.).
>
>What does it matter what the resolution is?
>Neither solution eliminates the spam channel, and
>solves the problem, as information theory shows.
>Its just a silly debate over two schemes to thread
>a needle that can't be threaded.

think of spam as a river passing through multiple
channels, let's find a channel we can change.
folks talk about spammers taking advantage of
email protocols.  another angle is to say that
spammers take advantage of people's behavior.
it's much easier to change my personal behavior
and expectations with regard to email than it is
for me to change an established internet protocol.
so stop thinking about eliminating the ability to
send spam and focus on *absolutely* identifying
real email.  spam will dry up as people are able
to absolutely identify real email.

>>That sounds like the old "authentication solves
>>spam" hope.  It was wrong before SMTP-AUTH and it
>>is still wrong.
>
>Guess what, it is impossible to "solve" spam the
>same way it is  impossible to "solve" burglary. At
>least with authentication you get to have
>whitelists that work. If you get a message with my
>email address in the "from" line it could be from
>anyone. If it is signed with my PGP key you know
>it came from me personally or someone went through
>a LOT of trouble to get access to my private key
>and the key phrase.
>
>The usefulness of authentication could be further
>extended by building a web of trust where people
>vouch for the fact that others aren't spammers.
>Obviously spammers will slip through from time to
>time, but anyone who spams or keeps vouching for
>spammers will be removed from the web of trust.
>But even if this part doesn't work authentication
>is still useful.

exactly

thread:  tidbits - digital signatures in tidbits --
---

>As I said earlier, I don't see the point of doing
>it for this list, but the mechanism itself isn't
>so easily spoofed.  Think of it as an address
>based whitelist with addresses that can't be
>forged.  A spammer wouldn't be able to get his own
>public key on the whitelist, and can't pretend to
>be someone else because he doesn't have the
>corresponding private key.  I personally wouldn't
>use such a system, since the Bayesian spam filter
>I use (bogofilter) works well enough, but people
>that are more annoyed with spam than I get might
>find such a system attractive.

exactly, my bayesian filter (POPFile) works great,
but i get so much spam that the 1% of my email
that doesn't get classified correctly is causing
me too much pain.

>>>Then you have to start allowing attachments on
>>>the list...not a great idea.
>>
>>Not necessarily. This should work as text only
>>with PGP 8.
>>
>>Attachment converted: HHBV HD:PGP.sig (pgDS/----
>>) (002B8C8F)
>
>Obviously, it does not work except by allowing
>attachments... and  it's hard to believe that
>TidBITS Talk would ever come to that.

no, digital signatures can be inline, the mime
attachment method is more robust but not required.
so tidbits can be signed without mime
attachments.  FWIW, most email clients do support
the mime method.

>>There are plenty of uses for digital
>>signatures, but I don't think approving mailing
>>list postings is likely to be one of them any time
>>soon.
>
>Agreed. Remember the messages that slipped
>through were approved by Adam because of poor html
>formatting, except one that forged his email.  If
>he used digital signatures most of those messages
>still would've been signed, and just like Habeas
>headers, if you're spam filter auto-whitelists
>signed messages they would come through.

exactly, if the list is signed spam can still get
through.  what the signature does is allow the
mailing list traffic to be positively identified
amidst the personal flood of spam many folks
receive.  just like we help list maintainers out
by taking extra steps to allow posting,
maintainers could help us out by signing all list
messages.  dealing with spam requires cooperation.

>>I think people should sign all of their
>>messages. That will have several effects:  - Peole
>>will get suspicious if a message isn't signed,
>>making forging mesages harder.
>
>How do you handle email from a kiosk, or a cell
>phone, or someone else's computer? There are too
>many instances in the real world where this
>happens. It's one of the benefits of IMAP..you
>don't HAVE to be on any particlular computer to
>get your email.

by locating signature verification at the mail
server level.  create a procmail recipe that will
automatically tag all signed email as to whether
or not the signature exists in the personal
whitelist that has been uploaded to the server.

>I do think we're getting off topic but -- any
>modern approach to the spam problem must take into
>account the fact that at any given time the
>Internet contains millions of insecure computers
>that can be taken over by viruses and used as
>zombies to, among other things, send spam.  If
>digital signatures were actually used in some
>standardized way, it would be trivial for the
>virus to grab it and sign its messages.

again, digital signatures as an anti-spam
technology will be effective for folks who don't
*need* to be able to be contacted by anyone on the
internet prior to them verifying they're not a
spammer.  folks that need to be this accessible
need to either modify this requirement, continue
to rely on statistical spam filtering tools, solve
the key distribution problem, and/or work to
change established internet protocols.

>This assumes that you already have all the keys
>of potential  correspondents in your keyring,
>which makes this just another form of
>whitelisting, albeit a cryptographically secured
>one. The shortcomings of whitelisting systems are
>well described here and elsewhere, but basically
>you'll have to read all your (signed) spam just to
>make sure there isn't a message there from someone
>you haven't whitelisted yet. Remember, too, that
>public keys really should expire, so you would
>need a method for keeping your whitelist (keyring)
>up to date. If you try to automate the whitelist,
>you open the door to spammers again.

you are assuming the receipt of email from a large
previous unknown group of entities.  if this is
you then you won't benefit from digital signatures
adopted on a small scale.  but if you are one of
the many folks who only receives email from a
small group of people then digital signatures
ensure that you will never miss one of their
messages.

>I'm a big proponent of cryptographic signatures;
>they just aren't the Final Ultimate Solution to
>Spam.

digital signatures don't do anything whatsoever to
end spam - they allow spam to be sent to > /dev/null

>Whitelists work great for those corresponding to
>just a few people. But they simply aren't pratical
>for participation in mail lists.

at the very least a digitally signed list (by the
list software/moderator) allows list recipients to
identify list traffic.  i do have my doubts about
how impractical it would be for the list
software/moderator to check for digital signatures
prior to posting messages from list members.
think gradual implementation, let go of the notion
of all members signing their posts, although they
might, and for every list member that does sign
that's one less post to be analyzed to see if it's
spam.

>>Whitelists work great for those corresponding
>>to just a few people. But they simply aren't
>>pratical for participation in mail lists.
>
>Sure they are. You are missing the whole point of
>how digital signatures would/should be
>implemented in a discussion list environment.
>
>It's not the end user who needs to verify the
>signature, it's the list processor.
>
>I subscribe to a list. As part of that process I
>provide the public  half of my key. Any message I
>submit to the list is signed by me using my
>private key. The list manager software then
>verifies my signature and passes the verified
>message on to the list or to the list moderator.
>This ensure that only messages written by bonefide
>members of the list get past on to the members of
>the list.
>
>The whole point is not to ensure that messages
>coming from the list are signed but to ensure that
>messages submitted to the list are signed.
>
>This also obviates the need for the list to
>support attachments and  makes pgp/mime a BETTER
>alternative to inline signing. The list  processor
>receives the messages, verifies the signature and
>strips the signature. I, as a subscriber to the
>list, never see the signature.
>
>Maybe, the list processor itself signs the
>messages it sends out. In which case I only need
>to have the one key (the public key for the list)
>in my keychain.

well said.  i differ only in that i would start by
having the list processor sign the list (what i
perceive to be a simpler yet positive step) rather
than trying to get list members to sign in order
to post.

>If we stop all counterspam measures by pointing
>out that they aren't the Final Ultimate Solution
>To Spam (TM), the situation will never improve.

here!  here!

---

From: Dave Aronson <[email-masked]>
Date: Wed, 25 Feb 2004 09:22:54 -0500

On Wed February 25 2004 05:50, [email-masked] wrote:

 > positively id the messages from this list.

Look in the normally-hidden headers.  Most lists have something unique 
there.  Usually it's something like a List-ID or X-Been-There line.  In 
this case:

 > Sender: [email-masked]

If your MUA doesn't allow filtering on any header line you choose 
(including ones that aren't usually there), I seriously suggest you 
look into getting a new MUA.

Okay, so it can be forged much more easily than a digsig.  Big deal.  I 
don't think any spammer is going to bother emailing us directly and 
forging that header.

 > i'm
 > spam filtering tools.

Having the latest tools means nothing, unless they are used right.  Are 
you keeping your spam definitions up to date, by either subscribing to 
someone else's updates, or constantly building and refining your own 
database (such as with Bayesian filters)?  Are you applying whitelists, 
AND heuristics?  Are you also very carefully applying blacklists?  Are 
you observing very carefully, and tweaking, just how "spammy" your 
heuristics have to label an email before you dump it?  Are you holding 
the borderline cases for review?

 > signature.

Requiring digsigs on a list would help cut down on spammers forging list 
members' addies to spam "only members can post" lists.  Also, this is 
one of the few lists where I'd think most people would be clueful 
enough to do it.

However, would it be worth the bother?  Unless there's some poor sod 
already spending tons of his own time filtering out such spam already, 
I'd say no.  (If there is, THANK YOU!  Been there, done that, ripped up 
the T-shirt in frustration.  You're doing a great job.)  I can't recall 
when I've last seen a spam here.

 > again, this won't stop machines from
 > it becomes compromised.

Eh?  Why would compromise necessarily change the keys?  How will they be 
notified?  Can you guarantee that the compromise won't include blocking 
such notifications?  What's the mechanism you envision for all this?  
Lay out a rough roadmap, and maybe we can work it up into a draft, and 
then have it accepted as an RFC.

Here's an alternate angle for you to chew on.  Try coming up with some 
sort of mechanism that could easily be built into all MUAs, MTAs, 
mailing list managers, anti-spam "solutions", and all other programs 
involved, such that a user can take some simple action to sign up for 
an email list, and have all email from that list automagically added to 
his whitelist, at each step of the chain, AND the list owner can verify 
irrefutably that Joe Luser (or at least someone at that email address) 
asked to be on the list, AND in a way that would be at least difficult, 
if not impossible, for someone to accidentally trigger by such simple 
actions as "previewing" an HTML email or viewing a web page.  Never 
mind whether the list ID can be forged by spammers, whether the list 
requires digsigs on submissions, or other such irrelevant details; I'm 
only interested in automating the verified signup and whitelisting 
process.  (Tho if you can automate that enough that Joe Luser groks it, 
that would be great!)  That's an idea I came up with a while back and 
haven't had the time to put serious work into.

 > apologies

You ask us to take the time to implement a new mechanism of dubious 
value.  Meanwhile, you won't take the time to mention our names so that 
we can at least go quickly to the part of your email that concerns us, 
nor break it up into individual pieces so as to at least preserve the 
subject lines.  Talk about cooperating....

 > and cooperating.

Long ago that might have been true.  Welcome to the Everlasting 
September.

 > and it can happen gradually.

It will probably have to!

As for the lengthy conglomeration of your replies to other messages, 
forget it, I for one am not slogging through that mess, even though I 
see you replied to something I wrote.

-- 
Dave Aronson, Senior Software Engineer, Secure Software Inc.
Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org
(Opinions above NOT those of securesw.com unless so stated!)
WE'RE HIRING developers, auditors, and VP of Prof. Services.

---

From: John Stracke <[email-masked]>
Date: Wed, 25 Feb 2004 09:53:31 -0500

Dave Aronson wrote:

>members' addies to spam "only members can post" lists.
>
Not necessarily.  Spam viruses would then start collecting people's 
private keys.

-- 
/================================================================\
|John Stracke      [email-masked]                         |
|Principal Engineer|http://www.centive.com                       |
|Centive           |My opinions are my own.                      |
|================================================================|
|How many roads must a man walk down before he admits he is LOST?|
\================================================================/

---

From: Dave Aronson <[email-masked]>
Date: Wed, 25 Feb 2004 10:25:33 -0500

On Wed February 25 2004 09:53, John Stracke wrote:

 > Dave Aronson wrote:
 > > Requiring digsigs on a list would help cut down on spammers forging
 > > list members' addies to spam "only members can post" lists.
 >

Theoretically possible, but at least it would significantly raise the 
bar.  Also, I would suppose that the people who use digsigs (at least 
with the current level of difficulty) are mostly clueful enough to 
avoid most viruses!  B-)

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 25 Feb 2004 07:47:57 -0800

gnulinux (now that's a verifiable identity):

please do the work yourself - collect signatures for your petition by mail 
to you, not to the list admins. They are busy trying to make next week's 
meeting work.

And please - point to working examples of lists using what you propose.

                 Harald

---

From: Dave Aronson <[email-masked]>
Date: Wed, 25 Feb 2004 10:25:33 -0500

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: John Stracke <[email-masked]>
Date: Wed, 25 Feb 2004 10:27:48 -0500

Dave Aronson wrote:

>bar.
Only one person needs to figure out how to do it.  Think script kiddies.

-- 
/=================================================================\
|John Stracke      [email-masked]                          |
|Principal Engineer|http://www.centive.com                        |
|Centive           |My opinions are my own.                       |
|=================================================================|
|"So we've strapped a Patriot missile onto Snorky here." "You said|
|that was a PROP!" "It's a *functional* prop." -- What's New, by  |
|Phil Foglio.                                                     |
\=================================================================/

---

From: Dave Aronson <[email-masked]>
Date: Wed, 25 Feb 2004 11:32:41 -0500

On Wed February 25 2004 10:27, John Stracke wrote:
 > > > Not necessarily.  Spam viruses would then start collecting
 > > > people's private keys.
 > >
 > > Theoretically possible, but at least it would significantly raise
 > > the bar.
 >

True again, but I still don't think that this additional usage of 
private keys would provide sufficient incentive for a virus author.  
What do they gain out of snarfing someone's private key, that they 
wouldn't gain without this proposal?  (For those tuning in late, it has 
unfortunately been pushed off the top, but boils down to mailing list 
processors being able to require and verify digital signatures on 
members' posts.)  It nets them the ability to spam digsig-protected 
mailing lists that the victim is on, until the victim cleans out the 
infection and changes his key.  BFD.  I suppose some twerp might do so 
just because he can, but I don't think this will provide the incentive.

Admittedly, there are *other* existing incentives, and will probably be 
more as digitally signed and/or encrypted email becomes more popular 
and easier to use, but that's a whole 'nother story.  These other 
incentives may cause such a virus to be written, and this mechanism may 
suffer as a result.

---

From: Ramiro Muñoz Muñoz <[email-masked]>
Date: Wed, 25 Feb 2004 17:47:34 +0100

Depend where the private key are, and this option at least will be a
barrier to spammers.

Ramiro Muñoz
AC Camerfirma SA

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de John
Stracke
Enviado el: miércoles, 25 de febrero de 2004 15:54
Para: [email-masked]
Asunto: Re: digital signature request

Dave Aronson wrote:

>list

---

From: [email-masked]
Date: Wed, 25 Feb 2004 08:50:44 -0800

> Having the latest tools means nothing, unless they are used right.  Are 

i'm using them correctly

> However, would it be worth the bother?  Unless there's some poor sod 

if it wasn't clear, having list members sign messages 
in order to post isn't my request.  it was just a 
comment about an additional possibility.

> mailing list managers, anti-spam "solutions", and all other programs 

designing a complex total solution isn't an approach 
that works for me.  in my experience small foolproof 
steps in the direction of my vision have proven to be 
much more fruitful.

> value.

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.  

> Meanwhile, you won't take the time to mention ournames so that

the posts i was replying to were part of lengthy 
threads around the same issue.  my intention was to 
collect various concerns and reply to them to help 
elucidate my perspective.  it was more efficient than 
trying to write commentary from scratch that covered 
all the same points.  i wasn't looking for specific 
dialogue with particular posters.  just wanted to use 
the existing dialogue to create a summary of sorts.

if you look you should notice that i did create three 
sections (for the three different threads i pulled 
posts from):

thread:  ietf - proposal for built-in spam burden
& email privacy protection
-----

thread:  ietf - how not to filter spam
-----

thread:  tidbits - digital signatures in tidbits
-----

the quotes under each section are taken from those 
particular threads.

> see you replied to something I wrote.

sorry you found the structure of my post unhelpful.  i 
did attempt to make it easy to peruse.  if it's not 
too much trouble i do request that you browse through 
the rest of my post.  i am very much wanting dialogue 
around the issue of having the list digitally signed 
by the list processor.

peace,

david

---

From: "Neil Carpenter" <[email-masked]>
Date: Wed, 25 Feb 2004 12:16:01 -0500

>traffic for any recipient who decides to verify 

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.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 25 Feb 2004 11:26:04 -0600

Thus spake <[email-masked]>
> >  > apologies to the folks whose comments i'm replying to for
> >  > not referencing their names (i didn't have the time).
> >

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.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: Dave Aronson <[email-masked]>
Date: Wed, 25 Feb 2004 12:10:07 -0500

On Wed February 25 2004 11:50, [email-masked] wrote:

 > if it's not
 > the rest of my post.

Already deleted, and I can't be arsed to go trash-digging right now.

 > i am very much wanting dialogue

Okay, my three cents (inflation):

If the folks who actually run the list find themselves a spare moment to 
breathe (not likely so soon before or after the meeting in Korea), it 
might be fairly easy to implement.

However, what does it gain us?  Authentication that the message in 
question, was indeed sent via the IETF list.  What does THAT gain us?  
The ability to separate it out from the spam.  (Note also the 
assumption that anything sent to, or at least received from, the IETF 
list is NOT spam.  That may hold for this list, but certainly not for 
all.)

On the other claw, using the Sender line for that purpose has been 
working just fine for me.  (It's forgeable, sure, but I see no sign 
that spammers have bothered to do so, and don't think it's likely that 
they will in the future.)  That's also trivial to set up in any decent 
MUA.  Same holds for the List-ID, X-Been-There, and other markers used 
by most other mailing lists.  Most cannot filter so easily (or at all) 
on the presence/absence or [in]validity of a digsig.  Sure, advanced 
tools such as procmail certainly can, but many of us don't even find it 
necessary to use such things at ALL yet, and they're awfully difficult 
for Joe Luser to set up for his mail from RANDOM-L.

Zero net gain, for at least some (and likely much) additional effort.  
Why bother?

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 25 Feb 2004 12:06:45 -0700 (MST)

> From: [email-masked]

> ...

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

Vernon Schryver    [email-masked]

---

From: [email-masked]
Date: Wed, 25 Feb 2004 11:50:24 -0800

> list is NOT spam.  That may hold for this list, but certainly not for 

my intention is to move in the direction of accepting 
only signed email.  this will allow me to route 
anything that doesn't include a whitelisted signature 
to /dev/null.  that's what having the list signed will 
gain me.

FYI, i made no assumption that a signed list would not 
contain spam.  in fact, i would be surprised if it did 
not.

> for Joe Luser to set up for his mail from RANDOM-L.

if signature validation is positioned at the mail 
server level then the tools you mentioned above can 
still be used.  signature validation at the mail 
server level can add a header line to indicate 
signature validation status.  additionally, if 
signature validation is located at the mail server 
level you might also choose to route all unwhitelisted 
mail to /dev/null so you don't have to download it.

> Zero net gain, for at least some (and likely much) additional effort.  

again, for me a significant gain, and i perceive that 
generating a key pair and configuring automatic 
signing of all list traffic will require a minor 
amount of effort.

david

---

From: Dave Aronson <[email-masked]>
Date: Wed, 25 Feb 2004 15:23:08 -0500

> > question, was indeed sent via the IETF list.  What does THAT gain
 > > us? The ability to separate it out from the spam.  (Note also the
 > > assumption that anything sent to, or at least received from, the
 > > IETF list is NOT spam.  That may hold for this list, but certainly
 > > not for all.)
 >

That's what it gains *you individually*, because of *your* specific 
plans.  But that's not what the IETF is about.  What does it gain J. 
Random Luser, or even any notable fraction of the users or 
organizations on the net?  Nothing.  What does it even gain the extant 
subscribers of this precise list?  Again, nothing.

 > contain spam.  in fact, i would be surprised if it did

Then the whole deal gains you next to nothing as a spam filter either.  
The whole deal gains you *only* the benefit of being one step further 
towards your goal of having your current legitimate contacts send you 
email with whitelisted digsigs.  Of course, any NEW contacts will be a 
whole 'nother story.

 > mail to /dev/null so you don't have to download it.

I still don't think it's going to be worthwhile, but at least this 
sounds technically feasible, though I doubt many ISPs would be willing 
spend the extra cycles to check sigs for you.  Go to the appropriate 
Working Group, discuss the concept, find out if any related work has 
yet been done, and come up with a draft telling us exactly what this 
header should say, how anything else would have to modified to deal 
with it, the security implications (don't forget about forgeability of 
the header lines), etc.  You may even get it accepted as an RFC, 'cuz 
with that approach, it sounds like there MAY be some benefits to SOME 
of the people whose email servers do such a thing, especially if 
someone runs a server where all the accounts expect to receive only 
properly signed emails.  But even so, don't expect everyone, let alone 
the IETF, to start signing their outbound email.

To get you started, here's what pops into my pointy little head:

The final MTA will be responsible for signature checking.  All other 
MTAs in the chain will not create nor, if somehow present, alter the 
header line.  The final MTA will insert 
"X-Signature-Verification-Status: $VERSION $FINGERPRINT $STATUS".  
$VERSION is a non-negative integer denoting the version number of the 
header line.  This is version 0.  Later versions may only add to 
previous versions; removing items is prohibited, so as to maintain 
backward compatibility.  $FINGERPRINT is the fingerprint of the key 
used.  $STATUS is "Success", "Failure", "Unsigned", or "Forged 
$OLDSTATUS".  $OLDSTATUS is again any of the above, recursively.  A 
"Forged" status indicates that the message arrived with an 
X-Signature-Verification-Status line already in it, with a $STATUS of 
$OLDSTATUS.  I cannot think of any reason why this would be legitimate; 
if you can, feel free to use a different indicator, but methinks it 
should still be indicated.  This scheme might be doable by simply 
passing the email through an add-on, rather than modding the MTA 
itself.  The MUA, when receiving or sorting mail, could filter on that 
header line the same way as any other.  This includes whitelisting (or 
blacklisting!) various key fingerprints.

---

From: David Morris <[email-masked]>
Date: Wed, 25 Feb 2004 12:24:30 -0800 (PST)

> with the current level of difficulty) are mostly clueful enough to

It also supposes that the private keys aren't protected with a passphrase.
The applications I use which use a pp key pair insist on a pass phrase.
Such protection will make bothering to collect private keys quite a bit
less interesting.

Dave Morris

---

From: John Stracke <[email-masked]>
Date: Wed, 25 Feb 2004 15:34:56 -0500

>It also supposes that the private keys aren't protected with a passphrase.
Nope.  All you need is a keystroke monitor.

-- 
/================================================\
|John Stracke      [email-masked]         |
|Principal Engineer|http://www.centive.com       |
|Centive           |My opinions are my own.      |
|================================================|
|I'm not imaginary. I'm ontologically challenged.|
\================================================/

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Feb 2004 16:15:11 -0500 (EST)

> my real email even though i'm employing the latest

There isn't any relation between "positively identifying the messages to 
this list", and "time spent culling spam".

Since there isn't any connection, being able to positively identify 
messages to the list won't save you any time culling spam.

> please give me the one

There are many ways to reasonably accurately identify mail to this list 
and distinguish it from all others: It is sent "to: [email-masked]".

I haven't seen very much spam that has that characteristic, so I don't 
think such spam is much of a problem, if any problem at all.

		--Dean

---

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

> think such spam is much of a problem, if any problem at all.

In fact, if you look at the full header:

Date: Wed, 25 Feb 2004 16:15:11 -0500 (EST)
From: Dean Anderson <[email-masked]>

you'll note that one can really be pretty certain a) that the message is
really from the ietf list; b) that it was originally sent from a
registered host whose IP number agrees with its claim of identity and
whose owner likes the notion of secured mail; c) that email to the list
is generically spam-scanned before being forwarded; d) that the
[email-masked] who authored the note is really who he appears to be
and is accountable and hence is not about to hawk a website purporting
to portray coeds showering and playing with their doggies on webcam.
[Where it is parenthetically amusing to note that "hawk" means both to
sell and to clear one's throat to spit out corrupt and tainted slime...]

This is all BEFORE examining content.  Then one can apply content
filters at YOUR end at whatever level of analysis and rejection you are
comfortable with.  Obviously too-quick a rejection on simple keywords
like "coeds", "showering" and "doggies" would be a mistake.  

This is all technology and protocol that exists now and in fact is in
place now, and doesn't require OTHER people to do a thing.  YOU have to
do something -- take charge of your own spam-destiny, so to speak.

Parsing a header isn't horribly difficult, either for a human or for a
piece of software.  I routinely do it visually if I have ANY DOUBT about
a message from a stranger or a friend being "really" from the purported
sender (for messages that make it through spamassassin).  I also
routinely do it if a personal message from a vendor (sales, but not
spam) makes it through SA and I am considering answering.  Messages
without a perfectly formed header and all hosts along the delivery path
both registered and identified correctly are rejected to the bit bucket
pro forma.  Spamassassin uses data parsed from the header for several of
its tests, and not just for blacklist checks.

Digitally signing a message to or from ietf adds absolutely nothing to
your ability to determine whether or not it is spam except the necessity
of maintain YET ANOTHER complex mapping between identity and number.  We
don't use the DNS-based one that we have as the rigorous basis of a
protocol-level accept/reject decision, in spite of the fact that it is
ubiquitous (and indeed already a critical component of the mail transfer
process), reliable and at least crudely secure.  At most lookups are
used to drive blacklists, but we don't automatically blacklist mail from
all unregistered/anonymous sites.

Why in the world does anyone think that digital signature maps with
several orders of magnitude more entities to track, more complexity, and
hence more opportunities for spoofing and finagling are going to succeed
where simple DNS hostname lookup has failed?

IMO a "no anonymous mail" rule (no mail accepted anywhere from
unregistered hosts) coupled with pretty stiff fines and legal penalties
for spam would associate accountability and penalty and cause an
immediate and drastic reduction of the problem.  Holding ISPs (and
providers of open relays and proxies) liable for the fines of their
clients if they bolt or "have no assets" would give ISPs a very strong
incentive to police their clients.  Obviously, the two would have to
come about together -- it is less useful to have fines and penalties
when the originating hosts have unregistered IP numbers that change
every two days and are nearly impossible to trace.

I think that this is fairly unlikely to come to pass, as lawmakers are
as likely as not to be spammers of a sort in their own right, soliciting
campaign contributions, distributing political "newsletters", using
email in a variety of edgy, mass distribution ways.  OTOH, they also get
spammed, as do their families, so one never knows -- some states are
slowly moving to control spam in law.

In the meantime, instead of burning a huge amount of human time and
energy just DISCUSSING the issue of universal keysigned mail (let alone
the hassle of implementing it for just one site), perhaps we can each
(in the words of Candide) "tend our own garden" and use one of the many
excellent filtering mechanisms already available, while teaching our
users to do the same.  If the proposal meets this much resistance and
"why bother" attitude here, imagine the resistance it will meet at the
ISP level and out in the real world, where time spent implementing
ANYTHING is pure money and maintenance time down the drain.

   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: Dave Aronson <[email-masked]>
Date: Thu, 26 Feb 2004 08:29:04 -0500

On Wed February 25 2004 16:15, Dean Anderson wrote:

 > There are many ways to reasonably accurately identify mail to this
 > list and distinguish it from all others: It is sent "to:
 > [email-masked]".

Nitpick: [email-masked] could be in the Cc, or worse yet Bcc, field.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 26 Feb 2004 20:11:18 -0500 (EST)

> where simple DNS hostname lookup has failed?

The reason is a little clearer when one considers that the main proponents
of this idea have businesses or business plans to sell services for
running the necessary infrastructure. As Bill Gates proved, the quickest
way to astronomical wealth is to sell something very cheap to nearly
everyone on the planet.  Since then, many people have been trying to come 
up with similar schemes.  Few have succeeded.

> every two days and are nearly impossible to trace.

There are reasons to have "anonymous email" as well as reasons to operate
open relays**.  Many ISPs operate open relays, and while the number of
open relays continues to grow--few are open by mistake--the number of
"spammers" abusing open relays continues to decline. Last May, the FTC
reported that only 5% of spam involves open relays. Recently, I had a hard
time finding an open relay abuse example in my current spamfolder. I'd
says its now even less than 5%.  Open relays provide no benefits to
spammers that they don't already have.  We also have email senders that
only send mail, but don't receive mail. This type of mail is
indistinguisable from anonymous email, because there is no way to "verify"
the sender. But there are also reasons to have license-plate anonymous
email as well, where the message isn't truly anonymous, but unless it is
part of a criminal act, no one can find out the identity.

It is a mistake to assume that only people use email. 

Below are two recent messages on the subject of Verizon "testing" whether
an email sender receives email.  This "test" isn't helping Verizon filter
spam.  In both the case I was responding to, and the case that Randy Bush
was responding to, the people were experiencing problems with temporary
SMTP error messages, and wondering what the problem was.

On Sat, 21 Feb 2004, Dean Anderson wrote:

>
> Verizon is trying to do a "sender verification test".  This is a dumb
> idea whose time didn't come.  But no matter.
>
> Here is a message from Randy Bush on the subject.  I frequently disagree
> with Randy, but in this case, I think he has the right idea.
>
>               --Dean
>
>
> =================
>
> > I think he's saying that they were unable to perform the
> > validation hence the 450.  If the validation was successful,
> > they'd return a 200 series code, if it was unsuccessful, they
> > would return a 500 series code.
>
> nice words, but crap.  due to needs to spool mail for sites in
> countries with very poor connectivity, mail spool time here is
> quite long.  if verizon and others seem unable to decide in weeks,
> why should i pay the penalty?
>
> but, i guess the problem is easily solved with exim config.  i have
> set it so that if it can not deliver to verizon in say one hour, it
> dumps the mail.
>
>     verizon.net        *           F,1h,5m
>
> life is simple, except for verizon users i guess.
>
> randy
>
>

On Sat, 21 Feb 2004, Dean Anderson wrote:

> Shouldn't reply to my own message. But in case it isn't clear, the
> reason this is a bad idea is:
>
> 1) Performance. Verizon's mail server has essentially doubled its load.
> If a mail server or nameserver (theirs or yours) is slow, it will cause
> a temporary failure, as you saw. If their nameserver is slow, or one
> fails, it will cause a performance knee with a storm of increasing defer
> retries which will quickly bring the server to its knees.
>
> 2) Many sites monitor "NOQUEUE" connections, and automatically blacklist
> those IP addresses which make too many NOQUEUE connections. A lot of
> "testing" by Verizon will automatically get them blacklisted.
>
> 3) There is no guarantee that a from: address receives email. This is a
> feature that spammers certainly exploit, but there is are legitimate
> reasons for this: many machine email senders send mail and never receive
> mail. Any mail for those robots will be rejected.  So the premise of the
> test (that every sender can be verified) is invalid.  Of course, any one
> stupid enough to violate 1 and 2 above, will certainly be unable to
> grasp the subtlety of this.
>
>               --Dean
>

> slowly moving to control spam in law.

Actually, the CAN-SPAM act supercedes all state laws on the subject.  
States have no or very little say in spam legislation.

> ANYTHING is pure money and maintenance time down the drain.

** The reasons for running open relays are obvious from the definition of
an open relay--An open relay is any relay which provides unauthenticated
service to anyone outside of the assigned IP address space.

There are a lot of people and computers outside of our assigned IP address
space who want to purchase some services from us.  There are quite a lot
of people or things who can't use SMTP AUTH either because their software
doesn't support the protocol, or because we don't have per-user accounts
for them. Those who don't have per-user accounts or don't receive email
can't use POP before SMTP, so they need open relay.  There are quite a lot
of people and electronic agents that can't use SMTP AUTH. There are also
quite a lot of people and electronic agents that can't use POP before
SMTP.

We have leased line customers with many offices that buy connectivity from
us and from other providers for some offices, yet use our relays. (They
want our HA services for their main office, but we are too expensive for
their outlying offices)  We have leased line customers who have outsourced
their email boxes to another provider that doen't provide SMTP relay
service outside their IP Address space.  For them, we relay for the domain
of the other provider (RMX can never work).  Others get leased access from
us, but dialup from someone else, and don't want to change configuration.  
We have customers that run their own mailservers, but want backup relay
service from us. Others that are consultants, and are often in the clients
office on the clients DHCP, and don't want to change configuration.  Etc,
etc, etc.

Having run open relays since 1996 (and before, but they weren't "my"  
servers until 1996), I am very familiar with the abuse of open relays.  
Though I didn't experience any open relay abuse before 1997, and then only
after telling some radicals that there were good reasons to run open
relays, it was my business interest to find out who was behind that abuse.  

The abuse of open relays is mainly done by radical antispammers attempting
to mail bomb people.  Real spammers never abused our relays--Not in 8
years of operations.  But we have tracked down a number of open relay
abusers. Our abusers were either 1) people not sending spam, but not
having permission to use our relays either, or 2) radical antispammers
(sometimes admins at other ISPs) who were either trying to get us to close
our relays, or trying to abuse someone else.  In one case, an abuse admin
at Verio was fired for repeatedly abusing our relays, and posted his story
to the spam-l list, blaming me for his termination.

When we blocked the open relay blacklists from scanning, our abuse dropped
off dramatically.  I did tests with submitting different IP addresses to
different blacklists, and logging the abuse and SMTP connections to each
of the addresses, and then "closing" the relay and having it "retested",
and then measuring the number of connections. The abuse rate was directly
related to the "advertisement" of the address by the blacklist.  I
concluded that the open relay blacklists were promoting the abuse of open
relays. 

We still get periodic abuse of our relays. Generally, after I post a
message like this, the abuse rate will spike.  We detect and block nearly
all of this abuse. Radical antispammers/open relay abusers never seem to
consider that relay use is probably logged, and that analysis of the logs
can reveal a great many things. Indeed, it was the tracking of relay
abuse, and the failure to find real spammers in the abuse of our relays
contrasted with the finding of antispammers performing the abuse that
first suggested to me that radical anti-spammers may be behind much spam
abuse.

The present decline of open relay abuse in the face of increasing numbers
of open relays also suggests a link to anti-spammers formerly conducting
the abuse but now becoming disinterested in doing so.  It seems that the
radicals think that by conducting abuse, they can get people motivated to
close relays, ban spam, etc. But in fact, the statistics of spam show
other things. CAN-SPAM is not blocking any spam, but is enabling the real
spammers to be distinguished from the fake spammers.  Whatever the fake
spammers do, their activities will be revealed.  If they quit, and real
spammers don't quit, we will see a reduction in spam that will be
attributed to the fake spammers. If they don't quit, we have the tools to
find them.

The really funny/odd thing about open relay abuse, is that it was only
radical antispammers (or the misled/uninformed) who believed that open
relays were involved in spam or useful to spammers.  The radicals believed
that by mailbombing people they thought were spammers, they were somehow
helping fight spam. The "proof"  of open relay abuse was mostly, if not
entirely, just the efforts of other radicals anti-spammers.  Real spammers
appear never to have shared the antispammer viewpoint on open relays.  If
they did, it was for a very short time.

MAPS RSS tried to publish "proof" of spam sent through open relays, but
examination of our logs revealed that the "spam" they published about one
of our relays was only sent to 4 MAPS-associated people. Dave Rand and
Paul Vixie were two of them.  Even that wasn't a genuine spam. It was just
a spam-like event staged by anti-spammers. Fake spam by fake spammers.

Most of the people who thought (or still think) that SMTP AUTH or POP
before SMTP were anti-spam solutions had limited experiences with email
services, and those experiences were generally limited to residential
(dialup/cable/dsl) ISP services or small companies that run their own mail
server and only provide accounts to their employees.  These people often
put their spam solutions in the context of "only people use email, and if
we could identify the people, we could exclude spammers".  The fallacy is
exposed by the fact that email isn't only used by people and that in a
civil context, you can't be certain of the identity of the other party.

So you ask, where did the notions about open relay abuse come from and is
there any truth to them?  If fact, there were problems with _anonymous_
relays, which are different from open relays. Sometime between 1993, when
the _anonymous_ relay problem was fixed, and 1997, when I first
encountered people talking about closing open relays, the radicals seem to
have lost track of the difference.  As I explain below, this problem has
nothing to do with open-ness, but rather a misplaced trust in reverse DNS
in 1986.

Subject : Re: A historical perspective on 
draft-ietf-dnsop-inaddr-required-04.txt
----- Message Text -----
On Wed, 2 Apr 2003, Dean Anderson wrote:

>
> Here is a message from Rob Austein to the TCP-IP mailing list from 1986,
> which puts a historical perspective on things.  Rob is responding to a
> message from [email-masked]. Given this was in 1986, the
> spam.itsc.sri.com hostname was well ahead of its time.
>
> Rob knew then that "the silly net" wouldn't have reverse working all the
> time, but thought this was broken. Apparently, he was under the
> impression then that reverse was not optional, but could be "broken".
>
> More significantly (in retrospect), Rob advocates that one shouldn't put
> numeric addresses in Received headers.  Of course, Rob wasn't the only
> person with this viewpoint. It is unfair to place this solely on Rob's
> shoulders. Although not clear from this message, he is accompanied in
> this viewpoint by many then, and who still share this view today.
>
> To the later chagrin of so many people, Rob's viewpoint was implemented
> in Sendmail.  It is unfortunate because we later learned by hard
> experience that if one used a machine without Reverse, or if reverse
> were configured to return misleading results, then one could send
> completely anonymous and untraceable email through a mail relay. It had
> nothing to do with the openness of the relay, though that was the early
> "fix".  Of course, even "closed" relays could be abused, and it would be
> impossible to identify the user of the relay.  The anonymous spam relay
> exploit was the result of misplaced trust placed in reverse, and the
> fact that an IP address wasn't put in the Received: header. It had
> nothing to do with the openness of the relay.  Some say this ability to
> anonymously abuse relays caused spam. Eventually, this behavior was
> changed in Sendmail and other MTA's in the early '90s.  Since then, it
> has been impossible to send anonymous email through an open or closed
> relay. This fact has not stopped people from promoting myths about open
> relays, however.
>
> It is really historically interesting that 17 years later, after so many
> obvious faults, failures, exploits, and even spam caused by misplaced
> trust in reverse DNS, that the same people are still promoting the same
> ideas.  It is a historical irony that some of the most vocal and ardent
> proponents of Reverse DNS want to use it to prevent spam.
>
>               --Dean
>
>
> Message from Rob Austein ([email-masked])
> Wed, 1 Oct 1986 16:00 EDT
> ==============
>
>     Date: Tuesday, 30 September 1986 13:29-EDT
>     From: The lost Bostonian <[email-masked]>
>     To: [email-masked], [email-masked]
>
>
>     If it is true that all IP implementations enable a server program to
>     determine the IP address of its peer, then the HELO command, and its
>     response could be eliminated, which would save us a few bytes.
> 
> 
> You are assuming that it is always possible to translate addresses to
> names and vice versa. Unfortunately, there are some people out in the
> world running domain nameservers who are totally clueless about what
> they are doing, and there are others who have the misfortune to be
> stuck behind a losing gateway or otherwise be unreachable much of the
> time. Do you really want to make it impossible to receive mail from
> some host because a third party is broken? Or have to put numeric
> addresses into the Recieved headers?
> 
> 
> The answer is to fix the silly net, not throw away features to save
> two IP packets.
> 
> 
> --Rob
> 
> ====================
> 
> 
> 
>

---

From: Dean Anderson <[email-masked]>
Date: Thu, 26 Feb 2004 20:29:01 -0500 (EST)

I should also note that my own message below that I quoted is hypocritical
on my part. If the mail was IETF mail or other important email, I would
have a different opinion. Of course, It was hypocritical of me to say that
mail to others is any less important to its senders and recipients.  I
should not have encouraged this type of behavior.  It shows that I too can
be disgusted with things, and encourage an inappropriate response to
stupid behavior.  It is certainly something that one should try to avoid
in oneself, and criticize in others.

		--Dean

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 27 Feb 2004 02:20:46 -0600

Folks,

I think this thread has deviated enough from its original intent that the
best place to continue it is on the ASRG list -- there's no point in
bothering the entire IETF with yet another anti-spam discussion.

S