[Asrg] 6. Proposals - Verification via RCPT TO callback

Hector,

At this point I believe we have begun to go in circles about your 
proposal. What I would like to do here, is to summarize in this thread 
our collective issues and objects, and for you to reply once to this 
thread with your opinions.
If you wish, you can go ahead and write up an analysis, following the 
checklist in the technical considerations document about these issues. 
Breaking down the different issues in several sections might help as well.
However, I would like to close this debate for some time, since I do not 
see any point in debating this topic right now. It seems to me that 
both sides are stuck to their opinions at the moment, and we need to 
take a breather. As you have mentioned, you are going to be deploying 
this system as multiple customer sites. What we would like to do, is for 
you to come back to the group in a few weeks with the results, and let 
us know if any of the issues we have raised played any difference. In 
order to have a totally objective analysis, we would recommend to run a 
bunch of control systems that do not have the method and than compare 
the results.

However, your separate point about the need to analyze the SMTP 
protocol, and its weaknesses, and then see where the protocol can be 
tightened and holes patched, has merit for future discussion and I would 
definatly like to continue that discussion in a new separate thread if 
we can keep your RCPT TO proposal separate from that discussion.
------

Some of the objections raised against the RCPT TO proposal:

* As the specifications stand right now, normal SMTP sites are not 
expecting RCPT TO callbacks to verify existance of email addresses. 
Since this is the current facts on the ground, your specific method has 
potential issues since the sender's server might not be willing to 
cooperate with your method, or even think of you as a malicious attack 
and null-route your server. Whether the RFCs assume or require a valid 
return address is irrelevant, the facts on the ground are that no one is 
expecting call backs.
* In other cases such as Yahoo, all RCPT TOs are responded to with "2xx" 
codes, and validation is delayed until after the DATA command. Since you 
cannot continue validation past the RCPT TO command in order to avoid 
the sender from receiving messages, your method has false positives.
* Nothing prevents a spammer from using someone else's return address, 
or operate a domain that answers "250" to all callbacks. Since 
established companies such as Yahoo do that as well, you will not be 
able to detect the difference between them and the spammers.
* There exists a potential for DDOS attacks with this method.

* There are very significant reasons why the authors of RFCs 2821 and 
2505 recommend for the VRFY command to be turned off. Many of these 
reasons are still applicable, and before recommending the change, we 
need to analyze *why* that decision was made in the first place, and why 
today's environment would be any different.
* In certain deployment scenarios, the outer SMTP server has no 
knowledge of the existance of email addresses, will accept all email, 
and will not be able to respond normally to call backs. Requiring a 
change in those cases, puts a burden on the administrators which can be 
avoided otherwise.
* The SMTP protocol is designed for as a protocol for servers to 
communicate. Therefore, the authentication that is logically needed, is 
verifying the servers themselves, as opposed to individual accounts.
* This method works today, but there is no guarantee it will work tomorrow.
-------------

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg