[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <af406b770606071214w50ec3bb3r15ac1fad1e7e3b54@mail.gmail.com>
Date: Wed Jun 7 20:14:16 2006
From: ademar.gonzalez at gmail.com (Ademar Gonzalez)
Subject: Strange Emails -- What are they?
On 6/7/06, Pam Patterson <ppatters@...co.com> wrote:
> Ademar Gonzalez wrote:
> > On 6/7/06, Simon Smith <simon@...soft.com> wrote:
> >> ok, that makes sense... will greylisting counter this?
> >
> > don't think graylisting will have much effect, each bot sending a few
> > mails.
>
> Greylisting works by temporarily rejecting the first email from a sender
> at an ip address to a recipient, and then waiting the see if the sending
> mail server tries again as it should. If the server retries, the
> ip:sender:recipient tuple is added to a database and not delayed ever again.
>
> Most spam-sending programs never retry, even with a temporary error. So
> greylisting would probably help in this case.
ok, i had a different greylisting in mind, will send the ip to the
database if the recipient doesn't exists (works amazing against
dictionary attacks). don't see too much sense in delaying the
reception of a message addressed to an existing account given the
volume of email we handle and given the fact that nothing stops the
spammer from sending/relaying through a real MTA. they have already
learned to queue.
> What would really help is SPF, if you can manage it. That way you can
> reject mail that claims to come from your domain but does not come from
> your mail servers. But this is all a bit OT, not really full disclosure.
>
> --
> Pam
yeah SPF is a good idea but incomplete, there is still the forwarders
problem. also you need to provide the means to your clients to edit
their SPF records (so they can add their ISP's mail server ips) and
then it becomes a support nigthmare from the clients that don't have
the knowledge to manage this. been there done that, too complicated.
regards.
ademar
Powered by blists - more mailing lists