Hector Santos wrote:
Yakov wrote:
And also, what is your definition of a "false positive"?
As a mail transport/gateway designer, I am basing the design on technical
comformity. Hence, a false positiive is restricting what is otherwise a
legit client connecting into the system to deliver mail.
There is nothing in the current IETF email standards that requires (1)
the sender's system to operate a valid MTA that responds to RCPT TOs for
the email account that is sending the email, and (2) must not accept
RCPT TOs to *any* address at its domain. For example, some domain owners
use "catch alls" also to accept all incomings, which is perfectly legit,
OR ISPs such as Yahoo that are doing this to stop harvesting and
dictionary attacks.
You should concentrate your efforts on technical conformity of the specs.
No solution will solve the spammer problem 100% and you will be beating a
dead horse trying to look for one. In my view, your only option is to make
conformity in the future SMTP functional specification a requirement with
server-implementation backward compatibility. That has nothing to do with
DNS, Mail Filters, SPAM vs NO SPAM, BULK vs NON-BULK, non-server vs server
based MTA clients, etc.
What I would like to do, is to go through the SMTP model step by step,
analyzing loopholes, and see what can be tightened and improved. Then
from there we can figure out which proposals can work.
Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Why are both drug addicts and computer aficionados both called
users?" (Clifford Stoll)
-------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg