What the IETF should do: Amend RFC 2822 (was: Re: spam)
for aliases is work the IETF should take on. -- Doug Sauder Hunny Software, Inc
Re: spam
Do we have to solve *the* spam problem? How about a much simpler, solvable problem that perhaps a large majority of email users struggle with? The hard problem is how to allow people to be generally accessible by email, but not so accessible that they get tons of spam. In other words, how they can participate in a public forum -- say a newsgroup or mailing list -- allowing other individuals to contact them with non-spam, while keeping the spam out. The easy problem is how to allow two consenting parties to communicate via email without interference from spam. Not everyone feels it's necessary that they participate in a public forum. Many would be happy if just the easy problem were solved. The easy problem has not been solved satisfactorily. Some options: 1. Get multiple email accounts. Some are throw-away accounts. Some are closely guarded, but eventually end up compromised. 2. Change email addresses from time to time. For many users, that, to them, means changing ISPs. 3. Just learn to live with spam. 4. Try a filter and live with false positives. Those are the options available to average email users. For more capable users, there is another option: 5. Some clever ad hoc solution. Like putting a special string in the subject line. As this easy problem is a truly solvable problem, and one that many people care about, why not solve it in a standard way? See my further comments below... Anthony Atkielski wrote: [snip] I think, though, that a more effective method would be to find something that one can require on each message and that is not trivially easy for a computer to do automatically. For example, the various admininstrations passing through the White House have long had a policy of establishing a secret number or similar text that must be placed on any incoming letter that is to be forwarded directly to the President or his family with minimal screening. The President and family then give this number to a select few people. Any correspondence without the number goes through all the usual screening. This works because the number is an out-of-band datum that the average sender is not likely to have. It is communicated from human being to human being, and isn't to be found anywhere in public. So it cannot be automatically added by a machine, nor can unauthorized people add it. A simple e-mail implementation of this would be to place a random string in the subject line of a message intended for a specific recipient that serves the same purpose as this secret number. The string would be different for each recipient, and the only way to obtain it would be through some out-of-band process (such as contacting the recipient by phone, or something). Since there would be no record of this anywhere that spammers could harvest, it would be impossible for spammers to include these numbers on outgoing mail. Very simple, and very effective. It would, however, be nice to have e-mail clients that automated this, by allow for a secret number field in address books that would make it possible to insert them automatically on outgoing mail (most clients already provide a way to filter for such numbers on incoming mail). As Anthony's suggestion implies, the solution is simple. It works like this: You can get into my email imbox because I authorized you to get in. You prove that you are authorized by presenting the secret that I provided to you. While some would prefer to re-engineer the entire Internet mail system, I just see that average users would be happy if email from their relatives, friends, co-workers, and acquaintances went into one folder, while everything else went into another folder, automatically. Why is that so hard to do? Why isn't it done? Personally, I think that plus aliases (also called subaddresses) are the best way to solve the easy problem. But I would be thrilled to see the problem solved for the sake of Joe Average User by whatever technique: plus aliases, secret number in the subject line, new mail header field, or any other good idea. Once that problem is solved sufficiently, we can go back to our research problems. BTW, some commercial enterprises are on to this idea in a big way. Just as one example, there is ZoEmail (www.zoemail.com). Digital signatures and similar authentication would work but are overkill. All you need is some bit of information that spammers cannot harvest, and the above random string fits that purpose. Spammers might pick up your address on a newsgroup or Web site, but they'd have no way of discovering your secret number. That simply provides message integrity ... Hash it and sign it with the public key of the recipient. That would work, because spammers would not have the public key, whereas legitimate senders would. However, I think the secret-number concept described above would be much similar and would be just as effective. -- Doug Sauder Hunny Software, Inc
What the IETF should do: Amend RFC 2822 (was: Re: spam)
for aliases is work the IETF should take on. -- Doug Sauder Hunny Software, Inc
RE: HTML better for small PDAs
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Thu, 22 Feb 2001 21:01:23 EST, you said: I am not sure I agree with the statement that in 10 years XML will be history. One of XML's greatest values is in the fact that it is a good format for long-term archiving of written material. Some very old material (several millenia old) is available in XML format -- that's more than the 32 years for RFC1. ;-) The reason old text has been converted to XML is not so that people can read it on a GameBoy, but so that it can be archived, indexed, converted to other formats, etc. 1) Was your millenia-old data *written in XML*, or was it *converted to* XML within the past 5 years? Duh!? ;-) Obviously, this is a rhetorical question. 2) Will you be able to find the DTD you need in 2035? Well-formed XML documents still have value even without a DTD. It's usually pretty easy to guess at what the elements mean. If the documents are of value to a lot of people at the time, then yes, you probably will be able to find the DTD and one or more style sheets. If it's just a historical document, then maybe or maybe not. I'll bet that you'd be able to find a plain text rendering of the document, though. An alternative point of view is that in 10 years XML will have achieved a critical mass, so that it becomes as entrenched as many other standards: ASCII, TCP/IP, C, etc. OK.. Wake me up in 2011 and I'll be MORE than happy to reconsider. ;) I don't have a crystal ball, and I have been around long enough to have seen fads come and go. XML seems to me to strike the right balance between simplicity and value-add, so that I would consider it a pretty safe bet for the long-term as a document format. Anyway, I don't expect that the IETF will be moving from plain text to any other format for years, if ever. For the most part, this discussion is academic. Here's a proposal though: how about multipart/alternative! ;-) Seriously, storage is incredibly cheap. Why not store documents in several formats? If the plain text rendering is the normative document, I don't think anyone would have a problem with that. Perhaps the RFC editor could accept documents using the DTD from M Rose as well as the normative plain text format. I'm not suggesting that the editor take on a lot of new work, just that XML documents, when submitted by authors, be made available from the Web. BTW, I have always liked the layout of the RFCs -- namely, that they are nicely paginated with page numbers and headers. On the other hand, HTML often doesn't print very well. -- Doug Sauder
RE: HTML better for small PDAs
Just a few final observations, then I'll bug out of the discussion. 1. Some folks scoff at the idea of reading I-Ds and RFCs on a PDA, yet they think it's necessary to accommodate those who would read them on 1950s-style teletypes or other old, outdated equipment. We say that lines should be, what, 76 characters long? Why? What about 40 characters per line? Then I could read the RFCs on my old Commodore 64 in addition to my PDA. ;-) What *is* the lowest common denominator, anyway? 2. RFCs have a limited lifetime. RFC 1 might be 32 years old, but it's probably only relevant to historians. Historians will probably find the tools they need to view old documents. So, if RFCs are maintained in a format that outlives the technology documented in the RFCs, then there's no problem, right? (Speaking from the aspect of archives.) Anyone know how long ASCII will be around? -- Doug Sauder
RE: VIRUS WARNING
Oh, I agree that we have to take responsibility for our own actions. I am absolutely responsible for allowing the macro to run. After I mistakenly ran the macro, my first thought was to neutralize it -- to stop it from spreading further -- by disabling the automatic running of macros. Unfortunately, Word paid more attention to what the macro wanted, than what *I* the user wanted. I said "DON'T RUN MACROS!!". The macro said "run macros." Guess who Word listened to? Do you see the catch? It's not a matter of not being responsible. I take the blame. But MS made it much easier for the virus to get the upper hand. The don't-run-macros option is only halfway useful if you can only turn it off, but can never turn it on again. At that time I knew very little about macros. The VBA editor seemed non-intuitive to use. I tried to remove the virus by deleting the VBA script, and that took several hours of research in MS Word How-To books. I finally ended up going out to a store and buying the virus clean-up software. -- Doug Sauder Software Engineer Broadsoft, Inc -Original Message- From: Castro, Edison M. (PCA) [mailto:[EMAIL PROTECTED]] Sent: Friday, May 12, 2000 08:45 To: 'Doug Sauder'; Castro, Edison M. (PCA); [EMAIL PROTECTED] Subject: RE: VIRUS WARNING Let's see if this reasoning holds water. Imagine your favorite OS, suppose that I send you a .pl file (Perl Script). You then make the "mistake" of saving it to the file system and then proceed to running the script. What do you think that script can do?. What will you have to do to fix your problem?. This is completely analogous to changing the default selection on the "Do you want to run this document's macros" dialog from "NO" to "YES". We have become a society of excuses people, nothing is our fault. It is always somebody else's fault. WE HAVE TO TAKE RESPONSIBILITY FOR OUR OWN ACTIONS ps: if I made this stupid mistake, I will immediately check what macros are included in the forsaken document and delete them. -Original Message- From: Doug Sauder [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 11, 2000 5:55 PM To: Castro, Edison M. (PCA); [EMAIL PROTECTED] Subject: RE: VIRUS WARNING -Original Message- From: Castro, Edison M. (PCA) [mailto:[EMAIL PROTECTED]] That is exactly the same way that all Windows virus work. As a Windows user (as well as other OSes), I can say that people have to be responsible for their actions. Whenever you receive any Email attachment, the only way that attachment can produce any damage is if you run it. At least in my copy of MS Word anytime I open a word document and it contains any macros, Word readily ask me if I want to allow the macro to execute. Not only that, this version of Word (2000) is configured to only ask me when a signed (with a certificate of a trusted party) macro is included. Suppose you made the mistake of opening a Word document with a VBA (Visual Basic for Applications) script virus. (I did this once and I am sharing a real-life experience.) The VBA script turns off the option that disables automatically running scripts. I kid you not! Next time you open a Word document that contains a script, you won't be asked whether you want to run it. If you go into the options settings and set the option to disable running scripts, you have done nothing, because the virus script runs when you close the document and turns the option back off again. At least not allowing macros to disable the don't-run-macros option seems reasonable to me, but it seemed to have escaped the engineers who created Microsoft Word. Doug Sauder Software Engineer Broadsoft, Inc
