From: Grant Taylor
Date: 2007-02-08 11:04:58 -0500
Subject: Re: Per user settings
More information..: http://www.milter.info/#Support
Derek J. Balling wrote:
> Your experiences can't really contradict what I said, because what I
> said is based on widespread adoption which -- thankfully --
> sender-callbacks has not achieved.
Well, my experience also states that Unix (and its derivatives) and
Novell servers are more stable and secure than Windows NT systems.
However, based the prevalence of NT systems, my experience (as well as
others) must be wrong too. Popularity does not equal correct.
Granted, your opinion and mine can and do differ. My opinion is based
on my experience, which DOES apparently differ from yours. You have not
been in my position / shoes. So please do NOT say what my experience
has and has not been. I would never dare to say what your experience
has been for the same reason.
> Assume "SPAM QUANTITY" = "SQ".
> Now implement sender verification. Yay! Short-term SQ is reduced.
> Spammers see this, start using "real" sender addresses.
> SQ returns to previous value. Boo!
> BUT, then all the blowback which was going to BAD addresses before now
> suddenly goes to REAL addresses. So all the blowback for bad-recipients,
> instead of going to addresses which don't exist, end up in REAL peoples
> Assume "BLOWBACK QUANTITY" = "BQ".
> Now users are dealing with (SQ+BQ) instead of just (SQ).
You are failing to take in to account that most spam is being rejected
at the gate. Seeing as how most spam (based on my experience) is from
bot nets and the likes running SMTP engines sending traffic directly to
servers, there is no DSN when they are rejected.
Now, if you would like to talk about a server that relayed a message to
a server that rejected the message where the relaying server is now
responsible for sending a DSN, there is a bit to talk about. That
relaying server probably should not have accepted the message to relay
in the first place. Further, the DSN that it sends (which should be an
RFC compliant DSN) will include information about where the message that
it received came from. This DSN will be sent to the spoofed sender.
IMHO this message, though possibly annoying, does serve a valid purpose.
Namely, this DSN informs the spoofed sender that someone / something
is falsely using their address. IMHO this *IS* a service. If enough of
these DSNs come in, the recipient will likely contact their email
administrator (possibly in a round about way), who will likely take some
action there in to solve the problem. One of the possible solutions
could be SPF records, Domain Keys, or even filtering DSNs such as only
allowing returning DSNs that contain a key indicating that the original
message was sent from their system (i.e. milter-null).
> A net reduction in the usefulness of e-mail, as there is now *more* crap
> in users' inboxes, not less.
If an email administrator is doing their job correctly, the DSNs that
are not valid, can be filtered out thus the end user has no idea that
this is happening. All the while, the email administrator is aware of
what is going on and being pro-active about the problem.
> You're under the incorrect assumption that a message has to be "abuse"
> to make the system "less useful". Sifting through a couple hundred
> bounce messages for a message you didn't even send can make your inbox
> just as useless as a hundred erectile dysfunction ads.
You appear to be under the assumption that users are unable to filter
said messages that do make it in to their in box. Let's not forget that
there are solutions to make it such that only valid DSNs make it in to
end users in boxes.
> Someone's going to generate a DSN there. It may not be *YOU*, but a DSN
> is going to get generated somewhere, in all likelihood.
Hum. you apparently have seen a spam bot that generates a DSN? I have
never seen such. As far as the few other servers that relayed a
message, well that is a much smaller problem than the bot nets. And as
I have stated, there are solutions to this too.
This Spam Tit-for-Tat game that we are all playing is a game of solve
the biggest problem here and now and then solve the next biggest problem
once we have the first solved.
Grant. . . .
Copyright 2009, 2012 by SnertSoft. All rights reserved.