Re: Hello from a new subscriber was Re: Just Wondering...

* 2004-04-13 James Craig Burley:

>>James Craig Burley <[email protected]> writes:
>>
>>If spammers have to hold spam on their own servers, the servers will
>>quickly be found out and blacklisted.
>
> That's a big "if"; spammers can exploit hijacked machines (zombies),
> which is how lots of UCE and vermin get distributed *today*.

how do i exploit a hijacked machine for im2k?  i'd have to store spam
there and have it send notifications.  the receiver would have to ignore
the contents of this notification and download the piece from the hijacked
machine.

> In particular, how a site gets onto any blacklist seems to depend
> mightily on *somebody* retrieving a message stored on that site and
> deciding it's UCE, UBE, or vermin, and that somebody somehow convincing a
> blacklist manager to take action based on their claim.
>
> Since those are currently among the weakest points of today's push-style
> (SMTP) system, I remain unconvinced im2000 will make for a substantial
> improvement in this area.

note that only few people will deliberatly download spam, so few
mail-stores will be nominated in the first place.

> Yup.  However, spammers and vermin authors will soon learn how to make up
> 80-character subject lines (assuming your model) that are very
> convincing.  People (and their MUAs) will ultimately have to base their
> decisions on the sender and recipient addresses, plus attributes of
> delivery such as injecting system (today's SMTP client), message store
> (today's SMTP relay), and very little else.

what should be part of a notification, then?  note that real spammers will
continue to use non-existent email addresses, so { subject, from, to, date,
X}, with X beeing a user negotiated set of message headers, might already
be enough to distinguish spam from ham.

but please, by all means go ahead and propose the headers you need.

>>As for receiving email, your client will need to pick up from many
>>different POP3 servers, rather than just picking up from one as now.
>
> Not necessarily POP3 servers, perhaps not even possible with them, not
> sure offhand.  Surely shims could work, but whether these would have to
> be im2000->shim->SMTP->POP3, I don't know offhand.

anonymous POP servers are allright for mailinglists.  see paul jarcs
http://multivac.cwru.edu/posterity/ (URL has problems!).

>>A spammer tries to forge an email sender.  Result: your client can't pick
>>up an email from a server that doesn't exist.
>
> That's a big advantage of im2000.  Although, I think you mean "tries to
> forge an outgoing message store"; im2000 per se doesn't really "care"
> about the identity of an email *sender*, or does it?

yes it does.  im2k message are supposed to be authenticated by a (possibly
PGP) key.

> The potentially-big disadvantages of im2000 include:
>
>   -  So many people accustomed to "instant" message-content
>      availability that there will be widespread configuring of local
>      message agents to automatically transfer incoming messages to
>      local stores anyway.  Spammers won't have to pay after all.

surely you would configure IMs not to do the job of MTAs.  but IMs and
MTAs might converge, they might both become capable of some negotiation
features.

>   -  Adoption requires SMTP compatibility (JdBP's "shims", I think he
>      calls them), but breaks a crucial SMTP feature, namely, bounces.
>
>      IMO if "we" are allowed to "break" SMTP's bounce feature, why
>      don't we just do that *now* and see how it goes?  We'd save $$$$$
>      on all the joe jobs out there as the breakage is implemented, in
>      favor of sender-side polling or success-only notification or
>      whatever.

bounces are no longer a crucial feature:  you either download a message or
you don't, period.

>   -  For true pull-style delivery to work, system must basically
>      assume no DNS caching is available or will work consistently,
>      since there will be insufficient locality of reference to make
>      caching useful.  So, expect long delays reading email as DNS
>      lookups of arbitrary incoming domain names are needed to retrieve
>      message contents.  (Today's DNS already likely taking a big hit
>      due to anti-UBE measures in email, and it'll likely get worse as
>      SPF and similar facilities get deployed.)
>
>   -  Given the above, is the huge cost of a rollout of a new email
>      system that makes *two* major changes to everyone's assumptions
>      about email works justifiable?  (Pull-style delivery is one
>      assumption; eliminating receipient-side notification of delivery
>      status, aka DSNs or bounces, in favor of sender-side polling, is
>      another.)

this is nonsense.  there are no bounces and DNS doesn't change.

> At some point in that timeframe, spammers and verminware authors will
> target (like never before, if they have played around with it before)
> im2000, exploiting its weaknesses *as deployed*, which will include
> weaknesses im2000's designers are currently assuming won't exist (just as
> SMTP's authors didn't envision today's balkanized SMTP implementation
> worldwide).  For example, "pink contracts" between owners of outgoing
> message stores and spammers will mean that users will have to choose,
> just as they do today, how aggressively they'll block potentially
> legitimate email in the hopes of blocking well-disguised spam and vermin.

understand that you don't "block" email, you just don't download it.

> That's assuming early protoypes prove workable.  With proper up-front
> research, such as simulations using tiny DNS caches on a mini-Internet,
> it might be quickly learned that the DNS cache problem and typical
> network latencies *will* lead to an unacceptable end-user experience,
> such that "real people" will refuse to use im2000 because it's "too slow
> reading mail".

this is pure speculation.

  clemens