This is where, and why, I take issue with filtering and discarding at the level of the SMTP server, unless the accept/reject decision can be made with 100% precision
Imagine a networking transport protocol such as TCP, that discarded packets not based on their header information (according to any protocol-level criterion you like) but on their CONTENT,
Actually stuff like this exists today, sometimes called "layer 7 switches". They're used to filter out HTTP worms and so on. But the comparison makes little sense as in TCP segments are part of an explicitly created session. When someone accepts the session, it's reasonable to assume they'll want to receive TCP segments that are part of this session.
The issue with email is that the only reasonable moment to reject messages is when you're still talking to the sender, so that a failure notice can be communicated back. Once the message has been accepted, you either have to deliver it, or you run the risk of false positives. Since non-false positives contain false return addresses most of the time sending back an indication that a message is rejected to the return address does more harm than good.
Note that filtering while a transport session exists ISN'T the same thing as filtering the transport stream itself: modifying SMTP such that any mention of our favorite medicine starting with a V is blocked makes it impossible for SMTP to function. However, rejecting messages that contain this word may or may not be appropriate, if the user isn't going to read them anyway rejecting them at the SMTP is the right thing to do as both silently dropping them or sending back failure notices is much worse.
For nearly all filtering programs, it is too easy to create a message that is filtered but shouldn't be.
That's why information that a message is filtered must find its way back to the sender, so that the sender can take appropriate action.
SMTP was designed to permit reasonably RELIABLE (simple) transport
SMTP isn't and has never been reliable.
Imagine the post office (the real one) opening your mail and examining content -- for most of us this alone would be a nightmare and invasion of privacy --
What world exactly are you living in? Never heard of bomb or anthrax letters?
And you're assuming some external entity is imposing an arbitrary policy here. Fact is that most people _want_ their service provider to filter out spam even using today's relatively unreliable mechanisms. I don't think worrying about a world where legitimate pharmaceutical messages are filtered out with no way to disable the filters is warranted at this point.
Now, all that it would take to control this end stage filtering and make
it much more reliable would be a federal law mandating that advertising
communications be sent in envelopes clearly labelled as such.
Yes, and all that we need to do to make sure people don't use psychotropic substances is make them illegal.
If we can't stop denial of service attacks that bring down entire networks causing very real monetary damage, how can we ever expect to be able to do something about spam, where any invidivual message is at most a slight nuisance, using laws that only apply to a few percent of the internet anyway?
I repeat, I see little for the IETF to do about spam at the protocol level
If you were a spammer (or selling bandwidth to spammers, or maybe even selling anti-spam software or services) you'd be saying the same thing. So this claim is very suspect. You need to back it up with *very* solid facts.
This is not the case for bidirectional encryption of email content. There it won't happen unless and until the IETF works out a practical way to make it work at the protocol level, since clearly ALL MTA's have to be able to manage the encryption.
You really don't get it, do you? Encrypting the transport between multiple hops is useless. Encryption needs to be end-to-end. But we both have per-hop and end-to-end encryption standardized, implemented and used *today*. (It's too late for me to go out and find all the RFC numbers.)
-- PGP key: 0x1B1FC4E6 ---> http://www.muada.com/iljitsch.gpgkey Fingerprint: CABE 3C2C 55D0 4D31 ED1A 2B6D 37E7 8439 1B1F C4E6
Attachment:
PGP.sig
Description: This is a digitally signed message part