On Thursday, May 29, 2003 4:55 PM, Yakov Shafranovich
[SMTP:research(_at_)solidmatrix(_dot_)com] wrote:
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.
8<...>8
I would say that the system is issuing a 'command rejected for policy reasons'
or 'mailbox unavailable' but these are human terms. The permenance of the
status code is the issue - 550.
Section 3.3
" ...If the recipient
is known not to be a deliverable address, the SMTP server returns a
550 reply, typically with a string such as "no such user - " and the
mailbox name (other circumstances and reply codes are possible).
This step of the procedure can be repeated any number of times."
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.
I tend to agree, but what is clear is that the status codes are meant to be
interpreted by 'automata' and not 'humans.'
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg