Bah, I give up.
Looks like I'll be relying on the Bayesian spam filtering in the
just-released-today Mozilla (v1.3). So much for reclaiming band width, I'll
just route spam to /dev/null because the client makers are much more willing
to take a stab at the problem than the server admins (who ironically are
suffering more).
You (We) all are never going to make any progress at this rate. No one wants
to adopt anything. No one wants to do anything more than bitch about it. It
must not be a big enough problem then.
You're going to have to make a commitment to SOMETHING SOMETIME. Jesus,
anything is better than what we have now. If you don't want to commit to
something then stop bitching and lay in the bed you made.
I think sender verification should be started. It is easily implemented and
we can stand to have significant gains rather easily. Even if we want to use
the RCPT-TO hack in the short term.
-----Original Message-----
From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
[mailto:Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu]
Sent: Thursday, March 13, 2003 4:13 PM
To: Jason Hihn
Cc: 'ASRG'
Subject: Re: [Asrg] Taking a step back (Was: Proxy your address)
On Thu, 13 Mar 2003 15:03:58 EST, Jason Hihn said:
Note: This should be considered different from a simple RCPT-TO
check. While
easily implemented as such, it can be used to validate an
address (violating
#0) IMHO RCPT-TO should not ever return an error until after
the socket is
closed. Then when it goes to return an unknown mailbox error, it ends up
doing a verify of the From address. This does several things. 1) It will
prevent unnecessary error messages being sent back to a no-good
address. 2)
It will slow/prevent address receiver verification.
So.. instead of giving them a '550 Piss Off' right then and there, you
go to all the effort of queueing it to disk and verifying the From:
afterwards, and then finding out that you can't double-bounce. Really
bad if you're being spammed by 100K things in a dictionary attack...
And this is a messy situation - you have to be able to distinguish between
double-bounces that should go to the postmaster because there's a real
problem, and spammer double bounces. Silently dropping all double
bounces is a bad idea...
verifies your email address before it sends out the image. Can
we come up
with a standard that requires all images (any binary content
really) to be
embedded? My preferred email client has a check box to "not load remote
images in mail", which works for me, but I fret over people
whose clients
aren't so careful.
Let's note a few things:
1) This is (as you noted) really an MUA issue.
2) There's often legitimate uses for it. If you're at the end of a slow
link, you may very well want to download your mail w/o images, and then
select 'load images' for certain pieces of mail and not others.
3) The same spammers that don't follow RFC822 won't follow your proposed
standard either.
4) Identify the major software vendors who have issues in this
area, and ask
whether they're likely to implement such a standard.
5) Making it a standard won't make people upgrade. Only user education or
forcing an upgrade on them will do that.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg