Subject: Re: [Asrg] TitanKey and "white lies"... (Faking SMTP hard errors "improves" C/R utility?)

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 29 May 2003 16:55:29 -0400

At 03:18 PM 5/29/2003 -0400, Bob Wyman wrote:
>[...]
>         While the process of generating challenges in response to
>"unknown" senders is normal, TitanKey claims that they do something
>unique in that in addition to the challenge mail, they also respond to
>the original mail by issuing a permanent "user unknown" SMTP error. They
>have filed at least one patent application for this process.
>         Whether or not this works, it is somewhat disquieting to think
>that the "solution" to the problem is to have our servers violate the
>SMTP protocol by sending false status codes. (Note: This would seem to
>call into question the claim on the TitanKey website that "The Titan Key
>follows all SMTP standards.") On the other hand, if it works, it
>works...
>[..]

I did some research on Titankey and ran some sample SMTP sessions against 
their system.  One sample session is as follows:

------snip-------
220 XXXXXX.com Service ready
helo noone.com
250 OK cybercominc-zzt Hello [68.27.139.139]
mail from: [email-masked]
250 OK  <[email-masked]> Sender ok
rcpt to: [email-masked]
550 unknown user <[email-masked]>
quit
221 XXXXXXXX.com Service closing transmission channel
------snip-------

According to section 4.2.2 of RFC 2821, the "550" error code means the 
following:

---snip---
550 Requested action not taken: mailbox unavailable
          (e.g., mailbox not found, no access, or command rejected
          for policy reasons)
---snip---

According to section 4.2.1:

---snip---
An SMTP reply consists of a three digit number (transmitted as three
    numeric characters) followed by some text unless specified otherwise
    in this document.  The number is for use by automata to determine
    what state to enter next; the text is for the human user.
----snip---

I am not defending or approving TitanKey, just pointing out that what they 
are doing is not against the RFCs, they are rejecting the message i.e. 
"requested action not taken". Their only problem is a misleading error 
messages that is parsed by humans anyway. I would say that they are not 
following the spirit of the law but the line of the law.

This in general brings back to an interesting point - can you use the 
spammers methods against them? This would mean a lie about codes like 
these, bounces, etc.

Yakov

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------  

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 29 May 2003 17:07:01 -0400

Yakov,

I'd like to be able to respond to the question

	Is there a standard of care for delivery and non-delivery?

in the affirmative.

E.g.,

The industry standard for MTA response when delivered mail addressed to a
local addressee for which service has been administratively disabled is:   

        "550 Mailbox disabled for this recipient"

Futzing about with 821 and 2821 means that when the Expert makes a statement
like the above, the nice man or woman in a suit representing someone who is
responding to a claim of breach of duty by asserting there is no standard
will have you to thank.

Lets not make judgements more difficult by making the norms elusive.

Eric