If I may add a comment..
With the pending release of our new mail server with all its new Anonymous
Access management features, which has been a tremendous success in its
field testing for the past 6-7 months, the new focus for future research
work is to see how to stop the attempts in the first place.
For the most part, our primary focus was "SMTP technical compliant." That
is the approach we took to solving or addressing this problem. It has
nothing to do with mail content interpretation or the intent of the sender.
I like to think it has been a successful approach and I was not surprise
because a) by far the overwhelming legitimate senders run legitimate
compliant systems, and b) by far, the overwhelming abusive senders run
non-compliant systems. So just based on this empirical reality, you can to
a high degree, address this problem, technically at SMTP.
However, from what we have learned with a consistent number of hits, the
questions are now:
- Why aren't these people learning?
- Why aren't they adapting to the enforcements?
- Why do they keep trying on what seems to be a daily schedule?
I think a flaw in the anti-spam research was that we gave these spammers
more credit than they deserve, that they will "change" to circumvent
whatever you may have. They have; at RFC 2822! Not at RFC 2821! And I
don't they will because after all, they exist because of the HOLES in RFC
2821. They are not going to change software to comply.
Once the SMTP technical enforcements are in place, the tracking/auditing
part will be significant. This is where the laws, such as CAM-SPAM will
come into play.
I will end it with this. What I am thinking for future support, is the
possibility of some automated "Cease and Desist" notification to inform the
sender that continued "system harassment" will not be tolerated. This can
be in a form of a special 55x response code just if only for tracking
purposes.
ciao
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Markus Stumpf" <maex-lists-email-ietf-mxcomp(_at_)Space(_dot_)Net>
To: "John Leslie" <john(_at_)jlc(_dot_)net>
Cc: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, April 06, 2004 9:56 AM
Subject: Re: What we are trying to accomplish
On Mon, Apr 05, 2004 at 08:48:59PM -0400, John Leslie wrote:
My point was that we have very good reasons to want to design
DNS records relating to HELO authorization, equally good reasons to
want DNS records relating to RFC2821-MAIL-FROM, and good, though
different, reasons to want RFC2822 authorization info. They don't
need to be the same reason.
Isn't that the wrong direction?
There are several problems with what is commonly called "spam".
There are (in no particular order)
- MTAs flooded with bounces due to joe jobs
- Mailboxes flooded with unwanted messages (which must not be "spam"
in the hard sense, but could also be because auf typos or on purpose
(we frequently get emails to blackhole(_at_)space(_dot_)net,
picard(_at_)space(_dot_)net
not because IMHO someone wants to do something bad, but they want to
hide their email address and choose something they think is (maybe)
unused, but as soon as they are added to mlists without bounce
handling or double-optin this is getting annoying).
- phishing (fake mails/addresses/similar addresses to trick users)
There are four types (in general) of MTAs this messages are sent
from:
- official MTAs of ISPs that provide Mail service to their customers
- official MTAs of companies sending out messages (their own or on
behalf of their customers (aka bulk mailers)).
- MTAs of private/home users that send out mail of that users
- abused hosts 0wend by crackers/spammers/...
What we have is a matrix of MTA types and message types.
IMHO we should look at which elements of the matrix either cause the
biggest harm or are the easiest to fix and define a "main target".
Maybe other "targets" have the same problem class and can be fixed
also, so they should be included in the strategy.
Once we have the main target we IMHO have enough proposals to choose
one and adopt it to fix the problem targets.
One more word on phishing.
What I really don't understand, if /I/ had the problem of being a bank
or ebay or amazon or paypal, I'd choose a system (be it PGP or S/MIME)
install a gateway and simply start signing /all/ my messages. This will
neither hurt nor make the emails unreadable to my customers, but it would
give a sign/push to e.g. MUA authors to better support this in the MUAs
and would probably lead to a better crypto infrastructure. And it would
ring bells if a message is from "paypa1" but the registered key does not
match.
So, IMHO solving this type of problem messages should not be on the high
prio list of this group.
\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"