[Discuss] anti-spam.
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Thu May 25 14:37:15 PDT 2006
On 2006-05-25 11:59-0700 Scott Petersen wrote:
> My mail server is Postfix and my greylisting tool is Postgrey.
>
> http://www.greylisting.org/ [...]
Scott, I would appreciate it if you would answer some further questions
about this technique based on the following quote from that reference:
"What happen is that each time a given mailbox receives an email from an
unknown contact (ip), that mail is rejected with a "try again
later"-message....".
(1) Does the technique really work at the individual mailbox (i.e.,
individual mail address) level? That would be bad since it tells the
spammers this particular mail address is legitimate. I presume that is a
bad description, and the whole SMTP server (e.g., users.sf.net) does the
greylist rather than individual mailboxes for a given SMTP server (e.g.,
username at users.sf.net).
(2) Later on the reference says the delay for unknown IP addresses gives a
chance for the black-listing tools to work. That sounds good, but from the
examples given it appears grey-listing works right at the SMTP server level
so there is no chance for spam to get through and immediately be recognized
as spam and black listed before the time delay is completed. That's fine if
there are a substantial fraction of SMTP servers that don't use grey-listing
or who have such a short delay that the grey-listing is ineffective. Such
spam-trap SMTP servers immediately get the spam and can black-list it in
time to help the grey-list servers who are delaying it. But who is going to
run such spam-trap SMTP servers, and how do you keep spammers from detecting
and simply avoiding those spam-trap sites?
>From such considerations, I believe grey-listing will work well for a while,
but in the long run it won't be nearly as effective. To be fair, in the long
run it will still have some value by adding a bit more genetic diversity
(variety of delay times) that spammers have to deal with, but that is about
it.
As Barbara said, we have been quite happy with SpamBayes for a long time
now. I retrain it about once a year, and have a quick look at the "unsure"
results (which are rarely anything but spam) about once a month or so.
Typically a well-trained SpamBayes lets in 2 or 3 spams into my mailbox per
month (which is the reason I am so lazy about retraining). The impression I
got from the Grumpy Editor's guides was there are other Bayesian filter
solutions that are effective as well although there are also some to avoid.
Another effective long-term solution to spam I can see is to increase Linux
(or other Unix) desktop share and reduce MS desktop market share. That
latter OS is notoriously difficult to secure by design so it's all too easy
for spammers to get control of users' MS boxes and use them as a spam server
unbeknownst to the owner of the box. Some on this list may claim this is
preaching to the choir, but I frankly don't find this important point about
the fundamental source of spam is made often enough even in Linux circles.
Anyhow, the long-term fight against spam is one of my motivations for
cheering on Ubuntu and other "desktop-oriented" Linux distros. If they
profit with a huge Linux desktop swell because of their general usability
and as a result of the security frustrations that MS desktop users have to
put up with, then we will all benefit from the reduction in MS spam servers
and therefore in the amount of spam we have to put up with. A reduction
from 95 per cent to 90 per cent MS desktop share is not going to make much
difference to the spam fight, but reducing the MS desktop share by a factor
of ten percent would be a huge benefit to the spam fight since it would
force spammers to try to take over Linux boxes which have a much larger
degree of diversity and security than MS boxes.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
More information about the Discuss
mailing list