Subject: [Asrg] My ideas...

From: "Preston, Tony" <[email-masked]>
Date: Thu, 27 Mar 2003 11:04:36 -0500

I am new to this list, but thought I would see if I could contribute
a bit here or there.

I have been programming for quite a while(30 yrs or so), worked on every
thing from simple applications to device drivers.  

I do have some questions about the solutions/ideas talked about.  I
was wondering why not have the "TO:" field be required to be verifiable
from each stop.   I know this would increase the bandwidth requirements
of each email, but it would also prevent unidentified emails (99% of
the spam I get are unidentified).   If the MTA would validate on 
arrival and unvalidated email gets rejected, you at least have an identified
user to squash when spammed.  

Next, I do think you need federal legislation that creates the email
equivalent of a "do not call" list that any legitimate bulk emailer
must consult.  I think it must be accepted that bulk emailers are
going to be around, will operate with/without your consent...

The problem I see is that on the sending end, anyone can create a
bulk email business for virtually no cost.
 
I personally use a whitelist for most of my expected email, but expect
to get several that are unexpected, but not spam.  The unexpected are
filtered, I get false positive and false negatives, I still have to 
get rid of the junk...(interesting enough, 99% of my spam is in html
email which I never read, if it gets to me as html and valid I tell
the person to use plain text and add them to my whitelist).  
 
Any solution that requires users to change their tools/upgrade/do something
different is OK, they have the incentive to do it so as to 
get rid of spam.
 
Any solution that requires an ISP to change/upgrade/do something different
is much less likely to happen since you still have open relys out there
that haven't been updated in years...  If it costs money it aint 
gonna happen.   Besides, my ISP could get into trouble if they started
blocking emails I wanted...  
 
The problem has to be solved on the sending end or you do not have
a solution.  The only ideas that seem to make sense are the idea of
validating the sender at each hop (then as more and more MTAs get 
updated to do this, the sender is better identified and can be blocked)
and the idea of estamps.
 
Tony Preston
Systems Engineer - AS&T Corp, Division of L3
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 27 Mar 2003 17:31:26 +0100

> updated to do this, the sender is better identified and can be blocked)

What exactly do you mean with "validating".
We have some 1000 POP3/IMAP customers that use our mailservers also for
relaying.
Should we disallow our customers to send emails with a different
envelope sender than the one they have authenticated (SMTP AUTH) with?
How about small companies that host their own mailserver?

If not and he uses  [email-masked], the SMTP server could go down a
chain of LDAP/X.500 server and query the server for example.com whether
[email-masked] exists.

This leads at least to three problems:
1) Those LDAP/X.500/whatever servers will be vulnarable to dict query
   attacks and will reveal valid email addresses that helps the bad guys
   to clean up and populate their databases
2) it reveals nothing about the identity of the sender. Everyone could
   use  [email-masked]  and no MTA has a chance to know whether it's
   real or fake.
3) it doesn't prevent spammers to allocate another 12345abcde.com domain
   for two weeks, set up a LDAP/X.500/whatever server that always
   answers "validated" and spam on.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 28 Mar 2003 00:19:42 -0500

>from each stop.   I know this would increase the bandwidth requirements

I'm not clear on what you mean by "To:" field.  The To: field is what 
the user and the MUA decide to put in the letter.  It has nothing to 
do with what gets delivered--that's on the envelope, which doesn't 
get seen by the user--just the transport.  There are lots of very 
valid reasons why you may not want everyone to see who is in the To: 
field, which is why mail programs provide Bcc.

But what does it mean to validate a To:?  How is that different from 
either receiving or bouncing the email message?

>going to be around, will operate with/without your consent...

See my posting on "RE: [Asrg] 5b. Opt-Out, 2nd version".  Email is 
not like the phone system.  Not only is opt-out unlikely to impact 
any of your spam, it's quite likely to increase it.

>the person to use plain text and add them to my whitelist).

A common techie comment.  However based on my involuntary wormalert 
survey (which is to say, I'm getting the email involuntarily--but I 
might as well use it while I have it), about 60% of "end-user" email 
is HTML.

>different is OK, they have the incentive to do it so as to

Only if the pain of the new something is less than the pain of spam.

>that haven't been updated in years...  If it costs money it aint

You forget the numbers.  ISPs number in the thousands.  Users in the 
hundred millions.  ISP upgrades are more likely.  Those open servers 
aren't ISP servers--they are small companies and clueless users. 
Different problem.

>blocking emails I wanted...

They almost certainly already do.

-- 
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: "M Wild" <[email-masked]>
Date: Thu, 27 Mar 2003 17:21:36 -0500

----- Original Message -----
From: "Preston, Tony" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 27, 2003 11:04 AM
Subject: [Asrg] My ideas...

> user to squash when spammed.

Welcome Tony - Reading this message I get the sense that you want to
validate the From: address rather than the To:  I am contemplating clueing
my MTA's in to actual valid users in the domain so that I can reject mail
that I know I won't be able to deliver.  The thought here is to reduce the
bounce messages to likely invalid free email accounts.  If the list members
have any thoughts on why this would be a Bad Plan(tm) I am open to hearing
them.  My first thougth on it is that my MTA will assist the spammers in
weeding out invalid accounts in my domain however that is balanced by not
having to send bounce messages (to the tune of 28000 I'm getting rid of now
just to get some spool space back) to sometimes unresponsive mail hosts.

> different is OK, they have the incentive to do it so as to

Um...I don't know.  I never ceased to be amazed by the number of customers
that we have that are using sub 200MHz Pentium boxes using IE 3.02/Microsoft
Mail as their client software.  Some folks just don't have the patience for
a 25MB download.

> blocking emails I wanted...

I am contemplating MTA configuration changes to try to reduce the load on my
servers.  IF there were an effective solution (IMHO) for spam would I
change/update/reconfigure my software?  In a heartbeat.  Adding horsepower
only puts off the day where the spam load overwhelms the aggregate capacity
of my mail servers.  It astounds me that I have more computing horsepower
than it took to put a man on the moon and the system still can't keep
up...ad this is with approximately 3500 mailboxes.  *sigh*

> updated to do this, the sender is better identified and can be blocked)

I disagree on this point.  I cannot control what other folks do with their
MTA's  I *CAN* control how my mail servers are configured, what software
they run and whatever else it takes to, if not solve, at least reduce the
problem.  This paragraph also supports my initial assertion that you want to
validate From: addresses.  This has been proposed in other threads and the
question that comes to my mind is "Isn't that what VRFY is for?"  I may be
mistaken.  Again, I appeal to the collective wisdom of the list.

Regards
Mike

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 28 Mar 2003 10:12:40 -0500

>them.  My first thougth on it is that my MTA will assist the spammers in

It is usually preferable to bounce messages at the SMTP prompt rather 
than later.  Most MTAs do know what accounts are valid.  Bouncing 
later makes things worse for everyone.

>Mail as their client software.  Some folks just don't have the patience for

There's a 25MB download to upgrade the speed of your Pentium?! :-)

Seriously, if they are running 200Mhz Pentium boxes, the odds that 
that 25MB upgrade is going to run at any reasonable speed on their 
box is pretty slim.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society