[BozemanLUG] Best spam filter

[Robert Potter]

What I don't like about the Greylisting technique described below, are
servers that will not make another attempted send for 24 - 48 hours which
we have experienced a few times this year now. In at least one of these
instances, the sender was a government agency so we were never afraid of
SPAM but they were trapped in our Greylisting and it caused some
frustration. I do not have much other than a gut feeling, but it seems that
this year we have seen an increase in mail servers being configured to take
longer on the resend/response.

Rob Potter

On Fri, Nov 16, 2012 at 2:46 PM, Gary <gary at montanalinux.org> wrote:

> Layers.
>   Since the content cannot be relied on 100%, watch the activity.
>   Greylisting takes the first contact and replies with 'Not available now,
> try later'.
> Many of the spambots don't follow RFC protocols very accurately and won't
> bother later.
> Ones that do properly, get whitelisted for a period of time.  That also
> gives blacklisting
> db's more time to register new bots.
> Some good descriptions at:
>   http://en.wikipedia.org/wiki/Greylisting/
>   http://www.greylisting.org/
>
> - Gary
>
> ----- Original Message -----
> From: "Scott Dowdle" <dowdle at montanalinux.org>
> To: "Bozeman Linux Users Group" <discuss at bozemanlug.org>
> Sent: Friday, November 16, 2012 12:07:40 PM
> Subject: Re: [BozemanLUG] Best spam filter
>
> Jordan.
>
> ----- Original Message -----
> > I think the problem is artificial intelligence. A human can quickly
> > identify spam, but from what I've seen most software is STILL bad at it.
> That
> > is what needs to be fixed.
>
> The difference here is that spam is unwanted unsolicited email.  If you
> want a newsletter from a product vendor, hopefully because you
> intentionally signed up for it, it isn't unwanted and it isn't
> unsolicited... but the email looks exactly the same if it is spam or if it
> isn't spam.  There is no way to make AI know what you wanted and what you
> didn't want... unless it were to be like a stateful firewall... where it
> can tell the difference between a new connection attempt, and one that is
> part of an existing conversation.  That seems really, really hard to me.
>
> I think the reason the big companies seem to be successful at it is
> because they have millions of customers... and I'm guessing they monitor
> when an email with a certain pattern goes to a lot of users and how the
> first batch of receivers react to it... and maybe harness their judgement
> to figure out what to do with it... but given the typical speedy delivery
> times of mails... that won't work either... but it could give patterns for
> future emails.  I think the more users you have and the more you can muck
> with their incoming, reading and marking patterns... the more data you have
> to base decisions on.  Most small to mid-size companies only have access to
> the incoming patterns... and not the reading and marking... but since
> people like Google have the vast majority if their account holders using
> their web-based client (gmail), they have access to so much (reading,
> marking, deleting) and more including addressbook, all sent emails, etc.
>  Our simple SMTP servers just don't have a
>  ccess to all of those I/O paths.
>
> TYL,
> --
> Scott Dowdle
> 704 Church Street
> Belgrade, MT 59714
> (406)388-0827 [home]
> (406)994-3931 [work]
> _______________________________________________
> Discuss mailing list
> Discuss at bozemanlug.org
> http://lists.bozemanlug.org/mailman/listinfo/discuss
> _______________________________________________
> Discuss mailing list
> Discuss at bozemanlug.org
> http://lists.bozemanlug.org/mailman/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bozemanlug.org/pipermail/discuss/attachments/20121116/bbf954a9/attachment.html