[Discuss] anti-spam.
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Thu May 25 17:42:52 PDT 2006
On 2006-05-25 16:26-0700 Scott Petersen wrote:
> On Thu, May 25, 2006 at 02:37:15PM -0700, Alan W. Irwin wrote:
>> (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).
>
> This technique works at the server level. Every time a new message
> arrives at the mail server, it has to identify who it is to, who it is
> from and the sending ip address. This "triplet" is checked against the
> greylisting database to see if it is listed. If it is not listed the
> server responds to the sender with a try again later message. It will
> continue to send the "try again later" message until the timeout is
> exceeded. (In my case 5 minutes) After that point, the "triplet" will be
> listed in the database and the transaction can continue. You will note
> that the the "triplet" is what is checked, not whether the individual
> recipient exists. This may vary between greylisting implementations.
Thanks for that clarifying explanation.
>
>> (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?
>
> That evaluation is the same as the one I arrived at, after reading the
> article. However, this black-listing will be helpful when spammers start
> resending messages.
>
>>> 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.
>
> The fundamental factor here, that I believe will let greylisting be a
> viable tool in to the future, is time. A spammer, typically, wants to
> send lots and lots and lots of messages as quickly as possible. They
> currently accomplish this but not fully following the SMTP RFC and not
> resending messages. In the future, even when they adapt and start
> resending, they will still be impacted by having to wait for the timeout
> and ensure that they get the mail sent within the window between the
> timeout and when the triplet is removed from the database. This will
> slow them down and I will get less spam.
>
> As well, when they do start re-sending, more e-mail will get through the
> greylisting. When that happens, if the first people who get the message
> submit the information to an on-line blacklisting service, the people
> after them will be able to take advantage of the informtion when the
> spammer does a resend for them.
>
> That being said, I am not all that comfortable with an on-line
> blacklisting service as it has all the same problems as a web filtering
> service. That is, trusting the data sources to evaluate a message as
> spam correctly and to not abuse the black list to block large blocks of
> IP addresses.
All good points. I can particularly relate to the last one since our e-mail
to various recipients who use black lists periodically gets blocked because
the Shaw SMTP server is put incorrectly on one black list or another, and it
always seems to take days for Shaw to get together with the black list
organizers to resolve the situation. Often I think the black list "cure" is
so poorly implemented it is worse than the disease. Thus, I am looking
forward to the days when these extraordinary anti-spam measures will no
longer be necessary because spammers will find it so difficult to break into
home computers to turn them into spam servers.
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