Friday, October 07, 2005

Re: [IP] announcing

on Friday, Oct 07, 2005 Steven Champeon wrote:

Ed Gerck wrote:

> But don't we have two different actors here? Encryption has to do
> with the end-user while the other points you mentioned have to do
> with sysadmins. For the user, those other points you mention not only
> have zero priority but they can't do a thing about them, even if they
> would want to.

OK, point granted. I guess all I am saying is that if I had to choose
one thing to fix, getting the world's mail servers to support RFC 2821
would take priority over getting the world's end users to encrypt all
their mail.

> My discussion paper asks why users don't encrypt. Sysadmins are not
> a significant part of the answer, I think.

Agreed. The lack of a common PKI, I think, is the major factor here.
Email (unencrypted) doesn't require a handshake and key exchange (or
at least, not one visible to and requiring action on the part of,
the end user - this transparency is made possible, of course, by the
sysadmins whose role you minimize).

> OTOH, encryption and signatures can make it a lot easier to reject
> spam and prevent email fraud, which backfire to sysadmins.

But that's a zero sum game. Either everyone encrypts, or you don't gain.
> >Nowadays it seems the marketing folks are running the show and have lost
> >touch with what a basic user needs. It's a terrible state of affairs.
> That's a problem and David Farber had problems with this too. But first note
> that PGP and Outlook are on opposing camps. Outlook works fine with
> RSA-S/MIME and MSFT has no interest in support anything PGP related.
> PGP folks don't like MSFT either. Also, as I will comment in Part II,
> there's a fundamental problem why PGP and S/MIME are not very useful
> for email encryption. The marketing folks, either way, face a losing
> battle. It's not even a matter of a better user interface, even if
> very clever.

I'm looking forward to part II.

Monday, October 03, 2005

Re: [IP] announcing

on Sun, Oct 02, 2005 at 12:53:40PM -0700, Ed Gerck wrote:
> Steven,
> Thanks for your interesting message, to help
> stir the pot. I published it in the site's
> blog and RSS, at
> BTW, did you read the paper in the site?

Yes. Don't get me wrong - I do think encryption is important, I just think it's a lot lower priority than those others I mentioned.

About Outlook, it comes with S/MIME encryption at
> no cost.PGP is also available free and. PGP is
> also free for personal use at hushmail as a web
> service.

We have several clients who use PGP (or GPG, in some cases) to protect email from Web forms, etc. Every time we've had to go in and try to find, download, and/or purchase the official "basic" PGP plugin package from, we've been baffled by the whole product line. It used to be you could just get a plugin (for Eudora, I'm sure, and probably also for Outlook, but I don't recall) that would allow you to
sign/encrypt/decrypt/verify messages, manage keys, and that was it.

Nowadays it seems the marketing folks are running the show and have lost touch with what a basic user needs. It's a terrible state of affairs.

Steven Champeon

Sunday, October 02, 2005

RE: [IP] announcing

It seems to me that encryption is the least of our problems, as complex, confusing, costly (tried to download a free PGP plugin for Outlook lately?) and as generally unnecessary as it is (for the vast majority of messages, anyway).

This is especially true and unsurprising when you realize that many mail servers out there:

- don't identify themselves (using HELO or EHLO) using strings that remotely resemble valid Internet host/domain names, as required in RFC 2821, section 4.1 ff. I've seen unbracketed IPs, RFC 1918 IPs, "localhost", "localhost.localdomain", ".", and my all-time fave:

schampeo@habanero:1029 $ host domain name pointer

- as such, don't reject much mail based on forged/bogus HELO, because hey! nobody does it properly, so it's not a valid grounds for refusing spam and viruses. This even though late 2003 saw massive attacks from worms and viruses that HELO'd with the NetBIOS name of the infected computer! Later versions learned that some folks blocked HELOs with no "." and so started appending a random ".com", ".net" or ".org" to the NetBIOS name of the infected computer. :/ I believe now that some append a legitimate domain name (so you get "" instead of just "oemcomputer"). No matter that the names don't exist.

- don't refuse mail, even when the sending "client" claims to be the IP or any of the hostnames known to the server (in other words, they walk up and say "Hi, I'm Dave Farber! Want some cheap meds?")

- accept unwanted messages, and then, after missing the chance to refuse inline, trust the almost always forged or bogus sender when generating NDN messages (known as "outscatter", a clarification of the older term, "backscatter", which was misleading), resulting in a flood of third party abuse and still more vectors for infection or promulgation of the spam.

- don't have matching forward and reverse DNS (or don't have rDNS at all, despite AOL's refusal to accept mail from such hosts)

- don't have reverse DNS that indicates that the server handles mail (or have rDNS that suggests that it's just part of a pool of dynamic addresses, or about which even less is known) so hapless mail admins can tell the difference between, say,

and the tens of thousands of other infected hosts that start with


in over a hundred domains (I know about at least 124 domains using that naming convention) that are actively spamming us. The example given is an edge case, as it has two PTRs, one given above, the other is Unfortunately, it HELOs as something else entirely. :/

-don't support SMTP AUTH or port 587 for submissions, because it's ridiculously complex to try to provide tech support for people using Outlook or other mail clients that don't support SMTP AUTH in a useful manner, or make enabling it such a battle that you may as well write a new client to save time.

- don't support TLS because they have to pay exorbitant fees to monopolists in order to use encryption

- don't block viruses inline, even though it's fairly obvious from simple header inspection which files are likely to be infected (or, more importantly, which files are likely to be able to exploit bugs in mail clients, due to the 3-character extension mapping) and instead accept likely infected mail, scan it, and sometimes even send a copy back to the (forged) "sender", spreading the virus further. Road Runner recently started /cleansing/ such messages and then sending an annoybot message to the (forged) "sender", even though nearly all modern mass mailing viruses are known to forge senders.

- don't include adequate audit trail for injected messages, such that they can be traced to the IP of origin (hotmail often inserts an IP in network space, due to a faulty NAT setup; gmail uses RFC 1918 10/8 addresses; cnchost/concentric,,,,,,,,,,,,,,,,,,, et al. all have lousy audit trails).

- don't wait for the remote server to issue a 220 greeting (gmail again,,,,,,,,,,,, etc.) before trying to send their messages - never mind that if the greeting isn't present it's not clear the remote server is even able to accept the message. It's the modern equivalent of picking up the phone to hear the telemarketer already deep into their spiel.

I know this because we receive a constant stream of outscatter from other hosts, to forged senders in domains we host mail for, which shows that the original messages these other hosts accepted failed all these tests and more. In short, more than a tenth of all email we handle here is the result of other people's failures to live up to basic best practices or the RFCs that define SMTP, period.

There are a lot of things that need to be more widely fixed before we should focus on how to protect the payload; we're lucky any of the messages we're trying to send are delivered at all, in the midst of all this pointless noise and the wretched poverty of basic RFC observance.

Steven Champeon

Saturday, October 01, 2005

Re: What Email Needs

Hi Ed,

Just read (part 1 of) your "What Email Needs" and was wondering...

You pose the question of why so few Email users actually use encryption, despite it being a very trivial exercise in popular MUAs.

Further to your musings, I'd suggest you consider the "but they can read it anyway" factor. Ever watched _any_ (reputedly) technologically advanced/informed dramatic TV show or movie (think 24, The Matrix, etc)? Ever noticed how the "good guys" always and bad guys occasionally (in fact, usually only if it is helpful to plot development) can guess any password (usually in less than five tries, or within seconds of some crucial deadline arriving) or break _any_ encryption system (with the application of some suitably "techie sounding" nonsense technology)?

Ever wondered what that does to Joe and Jane Public's perception of the value of using encryption?


Actually, I think encryption is used so little in Email mainly because the general populace really does not understand the abysmal _LACK_ of fitness to purpose that modern computers and their software (in their default configurations) provide. If our car manufacturers had been allowed a fraction of the leeway the computer industry enjoys in terms of providing "sloppy" products, the Pinto might well have been seen as the paragon of safety... Of course, the difference between cars and general purpose programmable computers of the kind that we seem to insist on foisting on folk is that the latter are immensely (in fact, "immeasurably") more complex, meaning that Joe and Jane Public are never going to have sufficient specialist knowledge to "properly" (and that subsumes "safely") use them. Cars are just soooo "dumb" in comparison, which is reflected in the level of car-specific knowledge necessary for their widespread, successful use.

This is not a "beat the luser" rant, but more a statement of disgust for the way the computer industry treats its customers...


Nick FitzGerald