----- Original Message -----
From: "Alan DeKok" <aland(_at_)ox(_dot_)org>
To: <asrg(_at_)ietf(_dot_)org>
Sent: Friday, November 28, 2003 11:03 AM
Subject: Re: [Asrg] 0. General - Inquiry about CallerID Verification
Am I seeing things? Why isn't the group homing in on this method which
basically says that the return path must be valid?
As noted in another message, a number of people *are* using this
method.
Yes, I understood this. Never claim it to be the first. But we just
implemented and in my expert opinion, it is the best solution out there
today to eliminate a majority of the spam, yet at the same time, first into
the protocol and doesn't required a change the DNS records.
However, I clearly understand how having "extra" information at the DNS
level will help the process. But that isn't there yet.
The problem with it is that it's a band-aid.
Most software solutions are "band-aids." I don't consider this a BAND-AID
because it is LOGIC that naturally and logically fits into MAIL FROM: state
point in the SMTP protocol state machine.
Is it 100%? No. It is not, for the obvious and stated reasons.
The purpose of ASRG is to see if there are other methods which will
reduce the spam problem. e.g. Reducing the amount of spam sent, which is
very different than
reducing the amount of spam received.
ASRG should change their emphasis and concentrate on REDUCING unauthorized
MTA at the protocol level. SPAM is only a symptom of the dearth of such
controls. e.g. The Caller ID methods prove that MAIL FROM: (and
HELO/EHLO) validation is (should be) a SMTP functional protocol (optional)
requirement. How it is done is a technical and implementation issue.
In other words, there is NOTHING that should be stopping the IETF from
modifying the RFC to say:
x.x.x HELO/EHLO
The client host domain may be subject to mail server implementation
validated with the following
response codes:
x.x.x MAIL FROM:
The client return path may be subject to mail server implementation
validated with the following
response codes:
it has nothing to do with the technical implementations or how a mail server
will accomplish this.
On the other hand, if the ASRG/IETF is looking to add some "details" to the
specification:
x.x.x MAIL FROM:
The client return path may be subject to mail server implementation
validated with the following
response codes:
....
The following RFC methods are recommended approaches.
then even better. But Yakov has said, you can't force everyone to use any
particular method. Others may find a better method or something that is
more internal to their operations. The goal is that it should be a
functionally defined in the specification to help designers do a better job,
and in addition help eliminate any future LEGAL issues brought on by
spammers. For systems to reject connecting MTA, it has to be because of
lack of technical compliance.
---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg