ietf-asrg
[Top] [All Lists]

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

2003-12-02 02:11:23
Yakov,

This will be my last comments on the matter.  I will provide future info on
our gamma testing results.

See my final inline comments below.

PS:  That I am no advocate of any particular method.  The less overhead the
better.  To me,  this is a functional specification issue.  Fix, clarify the
specs and everything will naturally follow.  It is that  with the current
implementation of the network, with no other change, other than performing a
return path check (which inherently includes a domain, mx and IP check),
you can amazingly solve 80% of the anonymous access problem - TODAY!

----- Original Message ----- 
From: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>; "ASRG"
<asrg(_at_)ietf(_dot_)org>
Sent: Monday, December 01, 2003 8:45 AM
Subject: [Asrg] 6. Proposals - Verification via RCPT TO callback

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.

Change the SPECS and it make it compliancy issue, and everyone who is
serious about addressing  costly spamming issus will gladly conform, upgrade
their software, or whatever.

* 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.

Once the SPECS are changed, YAHOO will support it because it works.  If they
don't, then they were never serious about solving the spammer problem on
their system.

* 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.

 Like anything else.  You don't need this method to do a  DDOS or malicious
attacks. But if we use the VRFY method, that will help reduce this
potential.   In additional, this can all be tracked and scaled.

* 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.

I understood the "red-herring" harvesting reason was used as a reason
against enabled the option or providing it in software:

OFF:
             VRFY/RCPT TO response:   TRUE
ON:
             VRFY/RCPT TO resposnse: TRUE or FALSE

As far as a SPAMMER is concern,  a constant TRUE response is all they want
to know!  So in my view, having it OFF perpertuates the problem.  Doesn't
help it.

* 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.

Configuration issue.  Not all servers need to use it.

* 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.

A CallerID system includes a DOMAIN check because it has to get there in the
first
place to verify the address. So it fails at the DOMAIN, you know it is a
SPOOF or
ZOMBIE site!!  Bingo, thats is what we WANT!

* This method works today, but there is no guarantee it will work
tomorrow.

Like anything else, but in this case, verifying a return path will always
work if the requirement is put into the specs that says it MUST NOT BE SPOOF
address.  Hey, maybe thats all you need to say:

  MAIL FROM:

   The Return Path address must not be a GHOST or SPOOF address.
   If one is provided,   the SMTP receiver will expect the address to
   be a valid return path as required as part of the DSN operations

   MAIL FROM Field Validation and Verification

   Per RFC section xxxx, the return path must conform to proper syntax.

   Server Implementations or installations may perform return path
   verification using various techniques outline in [xxxxxxxx] before
   mail will be accepted.

    If a 45x refusal code is returned:

            45x Return Path not a valid return path

   the client has the option to reenter a valid return path or end
   the session

    If a 45x refusal code is returned:

            45x Return Path not a valid return path

   the client should not continue and end the session.

   Server who choose not to verify the return path should continue
   with a 250 response code.

ciao

---
Hector Santos, CTO
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



<Prev in Thread] Current Thread [Next in Thread>