On 17-feb-04, at 23:47, Robert G. Brown wrote:
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
PGP.sig
Description: This is a digitally signed message part