ietf-asrg
[Top] [All Lists]

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

2003-05-29 14:06:15
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: XXXXX(_at_)solidmatrix(_dot_)com
250 OK  <XXXX(_at_)solidmatrix(_dot_)com> Sender ok
rcpt to: XXXXX(_at_)titankey(_dot_)com
550 unknown user <XXXXX(_at_)titankey(_dot_)com>
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 / <research(_at_)solidmatrix(_dot_)com>
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg