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

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 01 Dec 2003 08:45:42 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 2 Dec 2003 04:09:55 -0500

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" <[email-masked]>
To: "Hector Santos" <[email-masked]>; "ASRG"
<[email-masked]>
Sent: Monday, December 01, 2003 8:45 AM
Subject: [Asrg] 6. Proposals - Verification via RCPT TO callback

> return address is irrelevant, the facts on the ground are that no one is

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.

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

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

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

> change in those cases, puts a burden on the administrators which can be

Configuration issue.  Not all servers need to use it.

> 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

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 18 Dec 2003 16:08:47 -0500

----- Original Message ----- 
From: "Yakov Shafranovich" <[email-masked]>
To: "Hector Santos" <[email-masked]>; "ASRG"
<[email-masked]>
Sent: Monday, December 01, 2003 8:45 AM
Subject: 6. Proposals - Verification via RCPT TO callback

>As you have mentioned, you are going to be deploying

Its been two weeks <g>

I am putting together a summary report of our gamma testing.

Here is just the Santronics site only WCSAP log statistics and breakdown.  I
will provide some analysis now and provide more detail analysis in my report
gather logs from other gamma testers:

Stats for December 1 to 16, 2003

Total Sessions             :   31388
total rbl blocked          :   18887    60.17%
total non-rbl blocked      :   12501
total rbl cbv tested       :   11988
total cbv ready            :   24489
total filter unknowns      :   30415
total filter rejects       :      38
total filter accepts       :     107
total filter test          :     828
total cbv test             :   24344
total tries          :   23248
total rejected             :   23770    75.73%
total sap refused          :    8329    34.21%

total cbv tested           :   24344
total cbv bad              :   21366    87.77%
total cbv bad filter       :      38     0.16%
total cbv bad refused      :    8329    34.21%
total cbv bad ptr          :    2212     9.09%
total cbv bad no mx        :     521     2.14%
total cbv bad no mx host   :       0     0.00
total cbv bad connect      :    5207    21.39%
total cbv bad welcome      :    2042     8.39%
total cbv bad helo         :       7     0.03%
total cbv bad mail from    :       0     0.00%
total cbv bad rcpt         :       0     0.00%
total cbv bad open relay   :    2565    10.54%

total multiple mail from attempts :     870

Overall, the system has an average of 85-95% success rate.  In our case, its
88% for the month of December.  This rate does not include RBL rejected
sites.

As we were fine tuning it,  the last few days included a learning filter
algorithm to auto reject thus skipping the CBV process to reduce redundancy.

RBL is also included, which for the month of December, rejected 60%.
Since the RBL reject is optional, a CBV test can also be performed on RBL
rejected sites.  This help us in comparison the CBV against blacklisted
site.   Since some days I had it off and on, the above does not give you a
good comparison. To see the comparison, go to
http://www.winservercom/public/security.   You will see between Dec 4 and
15, when RBL rejection was disabled in WCSAP,  it failed slightly better
than RBL but I would say they are about here which some what indicates how
well the RBL sites work or rather the concept of having a low overhead
"central site" to validate a system.    But what this shows what RBL does
not cover, WCSAP makes it for it.

Some additional info:

Approximately 22% failed at the PTR, MX, Connect level.

8% failed to respond at the greeting.  However, this includes early data
where the WCSAP timeout was too low.  A new version installed a few days ago
solved this problem.

Approximately 11% tested as open relay sites.  Manual inspection shows this
is actually true positives with actual zombies or compromised sites.

The multiple mail from attempt counts is a initial analysis where I am going
to measure how the systems try multiple MAIL FROM commands when they get
rejected.  In this case, 870 systems tried more than one mail from.  Manual
inspection showed it came from specific sites using specific software.

One of the other test I am going to see is to analyze the software they use.
I  found quite a pattern here which I will detail in my report.

Of the issues raised:

1) Overhead, Redundancy
2) False Negatives/Positives

Solving the redundancy issue is the trick this system.   A learning/training
concept is suggested at the implementation level.

One method used in WCSAP is to pair the email domain with the connection IP
which I call DIP.  A accept/reject DIP filter is automatically created as
the system learns drastically reducing the redundancy.

The logic has been in place a day or so with the last 960+ sessions where
107 connections were accepted and 38 were rejected.

The speed of the system is fast, 1 to 2 seconds when there are no
DNS/connect issues which would add delays.  I added options to set timeouts.
The one timeout required was the greeting as I found some systems (both
legitimate and spammers) have long delays at the greeting.

Overhead would be an issue at the most fundamental level.  Redundancy logic
must be added.  In addition to the learning algorithm,   there is interest
to network the system using some kind of combined C/S, P2P topology of CBV
systems.   Another idea to reduce CBV overhead is to move the logic to the
RCPT TO stage.  If the server refuses the RCPT TO:, then there is no need to
call the CBV.   This has not been implemented yet, but our statistics show
that at least  75% of the RCPT TO are rejected.  Hence, 75% of the CBV calls
can be skipped.

The False Negatives are very negliable.  Of the 20 or so gamma systems,
only a few indicated reports by users at which point a DIP was manually
added. A more detail analysis will be provided of the false
negative/positives in my report.

In summary, this system works with CURRENT standards, a proof of concept is
shown that eliminates the majority of access issues using a SMTP compliancy
testing concept.  Overhead can be address using scalability measures and
both overhead and redundancy can be solved with advanced implementation.

Note: One tope I will discuss in my report is the technical engineering
principles we should be adhering too.  Here is a small part of it.

We (SMTP Server developers) have NO business trying to "interpret" what SPAM
is  with the exception of providing administrative policies.   No
consideration is made to mail context which is the how the ideal TRANSPORT
system show work.   In my opinion, its a MUTE point once you enforce
compliance with SMTP and now CAN-SPAM which requires a valid return path.
In the near future,  Customers who are looking for a SMTP system will ask
one basic question (regardless if they don't know what they talking about):

                "Is your system CAN-SPAM ready?"

Are you prepared to answer this?  Or are you prepared to argue with them?

If you want SMTP to be ready, two things must be done according to CAN-SPAM:

       1) Refine the specification to REMOVE all ambiguity about technical
compliance.  This
            includes dealing with the RETURN PATH and/or the VRFY command.

       2) To minimize overhead, add a new ESMTP which specifies the SUBJECT:

That's its!  Fundamental and simple!

        EHLO Spammer.com
        SUBJECT: straight from their subject line
        MAIL FROM:  [email-masked]
        RCPT TO: <targeruser>
        DATA
        QUIT

Otherwise, systems will be forced to accept the DATA to do post analysis
WHICH is NOT desirable.

The SPEC should make the SUBJECT an administrative policy issue.  If
required, the server will
issue a refusal is not provided.  Implementations can augment the logic
against what is provided
in the MAIL FROM and RCPT TO.

- VALIDATION OF THE RETURN PATH
- TOPIC IDENTIFICATION

and you are CAN-SPAM ready.

Until next time.

-- Hector

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 18 Dec 2003 16:18:29 -0500

----- Original Message ----- 
From: "Hector Santos" <[email-masked]>
To: "Yakov Shafranovich" <[email-masked]>; "ASRG" <[email-masked]>
Sent: Thursday, December 18, 2003 4:08 PM
Subject: [Asrg] Re: 6. Proposals - Verification via RCPT TO callback

> Approximately 22% failed at the PTR, MX, Connect level.

That should be 33%.  I just want to correct this because it is significant.
Most systems do provide an MX.  They must put a server behind it, but they
do comply with "DNS"  - so DNS based proposal need to realized that just
because they have a "record" in DNS, does not necessary mean its valid.

-- Hector