Indeed. As we noted last month on the topic of ingress filtering, you
have to catch this stuff on the _intake_ side, to have any real hope of
spotting the offenders.
Back to sender verification (equivalent of caller ID).
This would allow better reporting of AUP violations to the sending domain
from the receiving domain. Logs could be used to document the violation.
This is already present in most present MTA's. While the present
method might mean that a series of actions will be necessary, it does
point a direct finger at the immediately previous point in the SPAM
path.
As I said in a previous [private] message, I would be very interested
in reading about your solution. I hope that it takes personal privacy
and determined privateering into account, i.e., that a person will not
have their identity revealed without their consent, and that it does
not depend too heavily on the sender's software (which the SPAMMER's
will certainly write to their own needs), respectively.
AGIS is kicking this, along with other ideas around. We spent a great deal
of resources on the IEMMC thing, and that didn't work out well. Thought
I'd toss the caller ID idea out to get feedback from this list.
Phil Lawlor
President
AGIS
Voice - 313-730-1130
Fax - 313-563-6119
I have to applaud you for this -- lots of folks didn't think
the IEMMC thing would work (for exactly the same reasons that
it failed, interestingly enough), but unfortunately there was
no open channel of communication with y'all at that time.
If there's interest, I'd be happy to start up a mailing list
for backbone types to discuss this stuff, since there's likely
to be some debate as to whether it's on-topic for this list.
[ On Wed, October 29, 1997 at 18:00:15 (-0500), Phil Lawlor wrote: ]
Subject: Re: Tracking SPAM (Re: Spam Control Considered Harmful)
AGIS is kicking this, along with other ideas around. We spent a great deal
of resources on the IEMMC thing, and that didn't work out well. Thought
I'd toss the caller ID idea out to get feedback from this list.
I think you're partly on the right track.
However there's another very critical part of the picture that I've not
yet seen clear mention of: i.e. the concurrent implementation of limits
to SMTP server connectivity which must go hand in hand with audit trails
that can be used to clearly identify the originator and follow him
through all e-mail transactions until they completely leave the home
ISPs network. I.e. not only must connection origination information be
logged, so must all mail transactions originated by customers be
captured and logged. Without forcing the mail sender to go through an
auditable SMTP transaction with a mailer that the ISP controls with 100%
certainty then one cannot be certain to be able to identify the would-be
spammer due to missing links in the audit trail. Such controls can
obviously be implemented just as easily as the anti-ip-spoofing filters
that all ISPs should already be implementing.
I and a growing number of other people who've decided to fight spam have
been telling ISPs this is the only sure way to control the extremely
high and growing amount of third-party illegal relay abuse. (I might
note that such abuse has skyrocketed since the decline of the IEMMC.)
Unfortunately this puts a burden on ISPs that I'm not certain they are
quite ready or able to handle yet. Indeed I've heard relativley little
back from the constant stream of requests I send for implementation of
such controls with accompanying complaints about third-party abuse
originating from throw-away dial-up accounts.
Of course once a more substantial contract has been forged between an
ISP and a user (i.e. one that enforces an AUP and allows the ISP some
degree of certainty that they will be able to extract retribution for
breach of contract) then, and only then, might the ISP allow the
customer to bypass some of the auditing mechanisms under the assumption
(backed up by contract) that the customer will have in place their own
similar auditing mechanisms.