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

From: "Peter Kay" <[email-masked]>
Date: Thu, 29 May 2003 10:30:09 -1000

I made a conscious decision to use my "public" titan key address because
I gave explicit permisison ONLY to the list admin. 

I initialy did create a "VPM" ([email-masked], it still works
and anyone can try it) for this list but decided against it.

If I get large amounts of hate mail booing/hissing against my use of a
protected email I can switch back and use my VPM.

Peter

> -----Original Message-----
> From: Bob Wyman [mailto:[email-masked]] 
> Sent: Thursday, May 29, 2003 10:20 AM
> To: 'Richard Rognlie'; Peter Kay
> Cc: [email-masked]
> Subject: RE: [Asrg] RE: TitanKey and "white lies"... (Faking 
> SMTP hard errors "improves" C/R utility?)
> 
> 
> Richard Rognlie wrote: (re TitanKey)
> > Suddenly, anyone using your solution for mail sent
> > from an email list will be removed from that list the 
> > first time they get mailed and you respond with the 550.
> 
> 	The TitanKey guys would probably say that when 
> subscribing to a mailing list you should provide one of their 
> "Virtual Private Email Addresses" which are basically single 
> user email addresses (sender + recipient are hashed to 
> generate the "virtual" address). If a message is received 
> addressed to a valid "virtual" inbox, then a C/R sequence is 
> not initiated.
> 	These "Virtual Private Email Addresses" appear to be 
> very much the same method which I've discussed in a few 
> earlier notes, is used in TDMA, or is claimed in the Xircom 
> patent that Intel now owns. (see: USPTO 6,356,935).
> 
> 		bob wyman
> 
> 
> 
> 

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

---

From: "Peter Kay" <[email-masked]>
Date: Thu, 29 May 2003 11:07:34 -1000

Nope.

When users subscribe to lists, they user their VPM and everything works
fine, perfectly, and normally.

The "protected" email address is for use when you need to publish your
email address "in the wild".

Peter

> From: Richard Rognlie [mailto:[email-masked]] 
> Sent: Thursday, May 29, 2003 9:53 AM
> To: Peter Kay
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Asrg] RE: TitanKey and "white lies"... (Faking 
> On Thu, May 29, 2003 at 09:42:14AM -1000, Peter Kay wrote:
> > You raise a really good point: do we break SMTP compliance by lying?
> > 
> > We think that the fact that SMTP tells the truth is the 
> heart of all 
> > the spam problems in the first place.
> 
> by "lying" you've now broken any existing application that relies on 
> bounces for automated clean up.
> 
> Suddenly, anyone using your solution for mail sent from an 
> email list will be removed from that list the first time they 
> get mailed and you respond with the 550.  now they have to 
> resubscribe again.  
> 
> lather.  rinse.  repeat.
> 
> -- 
>  /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
>  \__/  \ | http://www.gamerz.net/rrognlie/    <[email-masked]>
>  /  \__/ | Today is the first day of the rest of your life.  
> Of course,
>  \__/    |    so was yesterday, and look how you screwed *that* up...

---

From: "Peter Kay" <[email-masked]>
Date: Thu, 29 May 2003 11:57:11 -1000

I went through that patent below (albeit very quickly). I guess one
might say we're similar, but we're not. 

VPMs allow the user to freely give out a public address that will goes
directly to the inbox, yet and not have to "kill it" when it gets in the
hands of spammers. 

If and when that happens, the VPM can get "locked down", allowing all
those that have previously sent to the VPM to continue to use it, yet
disallowing any future senders (via the dreaded bounce) use of it.

The patent referenced heavily below uses dig sigs, etc to authenticate.
We don't do that.

Peter

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 29 May 2003 18:40:15 -0400

At 05:07 PM 5/29/2003 -0400, Eric Brunner-Williams in Portland Maine wrote:
>[..]
>
>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"

Is it the error code that is an industry standard or the error message? 
What about:

"550 spam not accepted"

Would that make a difference?

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

---

From: "Eric Dean" <[email-masked]>
Date: Thu, 29 May 2003 20:16:41 -0400

> Look at TitanKey as another type of C/R system that issues challenges at
> the SMTP level. That's essentially what it is. As for pros and
> cons of C/R
> systems, that has been debated before many times. C/R systems exist and
> will increase, we are just making sense out of chaos here. Perhaps Eric
> Dean can add the STMP-reject method to his C/R draft.

Just a point of clarification..I'm looking at C/R interworking..a method for
automation and loop prevention...not at specifying how to build a C/R
system.  With respect to this particular response code method...I'm not sure
what should be done for interworking systems with that feature.

---

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 29 May 2003 21:31:32 -0400

On Thursday, May 29, 2003 5:39 PM, Bob Wyman [SMTP:[email-masked]] wrote:
> Yakov Shafronovich wrote:
> > According to section 4.2.2 of RFC 2821, the "550" error
> > code means the following:... 550 Requested action not
> > taken: mailbox unavailable (e.g., mailbox not found, no
> > access, or command rejected for policy reasons)
> 	Ok. Perhaps it was a bit strong to say that it was a "lie."
> Nonetheless, it would appear that spammer's programs are, in fact,
> pretty much helpless in determing whether the "550" was issued due to a
> mailbox not existing or because of "policy reasons." They are pretty
> much stuck with either removing the address that failed from their
> databases or providing legitimate reply-to/From addresses and trying to
> deal with the C/R process. [...]

I think that there may be evidence to substantiate an argument that the SMTP 
servers installed by some 'spammer' tools may actually implement a 
surreptitious channel for communication of status code information, given 
spammer 'adaptability' and if that is indeed the case then it is a short leap 
to co-opting MS access to determine whether the response was attended by a DSN 
or a C/R message.  This could all be blue sky, but ...

> 	Off-Topic: I wonder if the fact that issuing a "550" for "policy
> reasons" is explicitly mentioned in RFC2821 might call into question the
> validity of any patent claims that explicitly use the method defined in
> the RFC... One might claim that the RFC's provision of a means to reject
> for "policy reasons" did, in fact, anticipate precisely the methods
> being discussed here.

precisely.

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 29 May 2003 21:07:19 -0400

On Thursday, May 29, 2003 4:55 PM, Yakov Shafranovich 
[SMTP:[email-masked]] 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: [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.

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

---

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 29 May 2003 22:07:10 -0400

On Thursday, May 29, 2003 7:05 PM, Peter Kay [SMTP:[email-masked]] wrote:
8<...>8
> However, that being said, go ahead and try to send email using
> well-engineered mass emailing software and you will see that it does, in
> fact, remove your email address from the database.

I am very interested in proving the assertion of that claim.  If you have such 
software for testing, can it be made available to the group for forensic 
analysis of its function and as an attempt (at least by me) to gauge the devel. 
tree/path or adaptability of said technology?

> Can we say with absolute certainty that all spammers remove all bad
> emails? Of course not. But look at the feature set of most all
> mass-email software and you will see features to auto-delist email
> addresses with "hard bounces".

Do we really need to do that (not to mention they would probably be executed 
;-) or can this be accomplished through forensic and other examination of this 
software?

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Fri, 30 May 2003 23:34:30 -0400

On Friday, May 30, 2003 12:15 AM, Scott Nelson [SMTP:[email-masked]] wrote:
> At 10:14 PM 5/29/03 -0400, Eric D. Williams wrote:
> >On Thursday, May 29, 2003 5:30 PM, Barry Shein [SMTP:[email-masked]]
> >wrote:
> >8<...>8
> >> Yeah sure and I'm the King of the Gypsies...
> >>
> >> Maybe a better way to say that is:
> >>
> >>       Since IN THEORY there MIGHT exist a spamming program
> >>       which responds to a permanent SMTP error...
> >>
> >> How is a virus-hijacked thrall server going to remove addresses or
> >> even report the error back?
8<...>8

> Different spammers behave differently, have different software,
> capabilities, and adaptability.  It might be interesting to
> examine some spamming software, but for it to be relevant,
> you'd need to connect it to actual sent spam and that's not easy.

I do not see that as a significant hurdle that could not be created in a 
laboratory setting.  The interesting bit to me would/will be that in such an 
environment all aspects of the process could be subject to analysis.  That 
analysis could also lead to a tactical or strategic advantage and/or identify 
tactical or strategic weakness we may not be aware of, regardless of the 
potentials if this type of analysis has not been done we can not 'know' as has 
been said 'anything' more.

> A much simpler way to gather the data IMO, is to take a few spam
> traps and have them start rejecting with 5xx.
> Then count how many RCPT TOs they get compared to other spam trap
> addresses that had a comparable amount but don't reject with 5xx.

That indeed is also a good testing venue, however fundamentally different than 
what I am positing.  I'm certainly amenable to any viable test method and would 
welcome such results but having a controlled environment with an ability to 
manipulate each variable independently and gauge the 'potential' adaptability 
metrics is still, I think, worthwhile.

-e