Re: [Exim] Temporary defer on callouts

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Edgar Lovecraft
Dátum:  
Címzett: exim-users
Tárgy: Re: [Exim] Temporary defer on callouts
> Date: Fri, 30 Jan 2004 16:41:32 -0800
> From:        Bill Moseley <moseley@???>
> To:        exim-users@???
> Subject:    [Exim] Temporary defer on callouts

>
> I'm now rejecting based on a failed sender callout. I'm using defer_ok
> on the callout which does allow a few bad apples through. Are others
> that are rejecting by sender callouts also using deny_ok?
>

I currently use the deny_ok in sender callout verification, that is not
where the problem is. I am currently working on a better solution than
the callouts (or atleast more selective callouts) as there are WAY too
many 'legite' domains out there that do not accept the 'mail from: <>'
command, so I get alot of complaints from users about so-and-so not being
able to send them email any more...
I have also found that this problem has just gotte worse this week as
even more silly admins seem to think that not accepting mail from: <> is
a good way to stop the virus, or more likely all of the
MailScanner/TrendMicro/NortonAV reject messages.
>
> I'd like to deny on timeout/temporary error, but I think that might be
> too extreme. So, I'm wondering if it would be possible to somehow give
> a temporary error, but cache the event and if they try again in an hour
> or longer then accept.
>
> The idea is that spammers may not try again on a temporary error, but
> legitimate mail would try again.
>
> Is something like that possible -- or even a good idea?
>
> BTW -- I notice in my logs that many of the rejects are three at a time.
> That is, I see this listed three times in a row in the log:
>
> rejected RCPT <ted@???>: Unrouteable address
>
> Is that just the way the spammer/virus is programmed to try? Or is
> there another reason for three attempts in a row?
>
> --
> Bill Moseley
> moseley@???
>
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
> details at http://www.exim.org/ ##



--

--EAL--