dwmw2 at infradead
Jun 27, 2009, 10:38 AM
Post #45 of 48
(2325 views)
Permalink
|
On Sat, 2009-06-27 at 21:00 +0400, Dmitry Samersoff wrote:
> David,
>
> >>> A separate dæmon written in C++ with a 'thread pool' implementation and
> >>> weird OS 'abstraction' layers to handle signals... that's not overkill?
> >> It's really fast and scalable (actually what it was written for - one of
> >> mid size ISP asked me for help). Also it couldn't cause email loss -
> >> i.e. if something goes wrong e-mail just passed in.
> >
> > Sounds like it's being used too much. Ideally, I believe greylisting
> > should only be invoked for mails which look suspicious in some way, if
> > they come from a host which hasn't previously been observed to queue and
> > retry.
>
> I try to greylist all incoming mail as early as possible to minimize
> relay load and (less important) traffic.
>
> >>> You also don't seem to be passing it anything other than $sender_address
> >>> and $sender_host_address -- and you're even assuming the latter is
> >>> Legacy IP, afaict.
> >> I'm checking sender host address and sender from address, e.g:
> >> 209.85.218.168:*@gmail.com
> >
> > How's it going to cope with what I get on your incoming mail:
> > 2001:4830:2446:ff00:214:51ff:fe65:c65c:dms [at] beastsoft
>
> What is it? MSG ID? My outgoing e-mail not graylisted - I use
> login/pass & SSL.
That's just $sender_host_address:$sender_address for the mail that you
sent, on one of its hops on the way to me.
I was asking how your code would cope with it, if I was using your code.
> > There is some discussion of that on the wiki page to which I referred.
>
> Some comments on wiki page:
>
> I.
> "One problem is that some "genuine" mail servers might be broken in the
> same way as we expect the spam bots to be."
>
> Much more often problem is clusters: lots of SMTP clusters can resend
> e-mail from another IP address. Fortunately most of them is not
> spammers. I think a) the problem should be mentioned in this chapter b)
> it's better to whitelist such clusters rather then exclude sender IP
> from hash calculation.
That would be nice if we know where they are. If they're on the dnswl,
they _will_ be skipped by the configuration I suggest.
But that's still not sufficient for the hosts that aren't -- the problem
is that if you include the sender IP in the hash, you'll settle into a
mode where you _always_ defer the mail from the first MTA, and always
accept it from the backup, when it's deferred. You're forcing your mail
to _always_ go through a slower path than it needs to.
> II.
>
> "Firstly, there's the database of "known resenders", which lists the
> hosts that are known to retry sending mail."
>
> In the NAT world I'm in doubt that such list have a sense.
That's why we use $sender_helo_name _and_ $sender_host_address, rather
than just $sender_host_address.
It's not perfect, but the alternative is that you just keep on deferring
mail from the same hosts over and over again, even though you gain no
benefit by doing so. You can of course do that if you wish, but many
people won't want to.
--
dwmw2
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
|
exim-gris.c
signature.asc
