On Thu, 2003-10-30 at 18:51 +0000, Alan J. Flavell wrote:
> On Thu, 30 Oct 2003, David Woodhouse wrote:
>
> > My dialup account
>
> I've no expertise with intermittently-connected MTAs, but the rest of
> the question seems interesting even so...
Apart from this week (ask me about how much I love British Telecom) it's
_not_ intermittently connected. It's dialup, but it's permanently
connected; or at least it will be when they finally manage to install
the ISDN line they said was going to be installed the day we moved...
> > gets lots of spam, much of it from domains for which
> > sender verification attempts _always_ result in a 'temporary' failure;
> > causing a 4xx rejection and my ISP to continue attempting to resend the
> > mail to me ad infinitum.
>
> Sounds a familiar scenario, except that "infinitum" shouldn't be more
> than 5 or 7 days?
It's longer than that, and may well be infinite. It's Demon Internet's
mail host -- it'll try sending mail by SMTP whenever I reconnect (and
some other times besides although bizarrely not when I ETRN) and will
keep it for a _long_ time without bouncing it. It's _designed_ for
intermittent connections.
> Even so: for spams, that time is too high, and can
> leave quite a lot of noise in the logs, especially if the offering MTA
> has too enthusiastic a retry strategy.
I'm more concerned that the offering MTA offers me the 300-odd spams it
has on its queue before the one real mail I wanted.
> On our relatively small-scale
> mailer, when I spot such behaviour in the log I drop the offending
> domain manually into an "unreachable_domains" list.
>
> deny sender_domains = partial-dbm;CONFIG_DIR/unreach_domains.db
> message = We are currently unable to accept mail from \
> $sender_address_domain\n\
> because that mail domain is persistently unreachable or not\n\
> responding properly, for reasons that are outside our control.
> [...and so on...]
>
> I also, now and again, run a manual script which simulates callouts to
> those blacklisted domains, and suggests candidates for removal from
> the blacklist. It's not very good, just a bit of hand-knitted Perl
> (actually it would be useful to have some kind of "exim -btXXX ..."
> option which tested address callouts using exim's own callout
> strategy...)
>
> > We already cache address verification results.... can we also cache
> > temporary failures,
> Let me say what I think you meant, just so we're clear: you want to
> make a fresh callout each time, but in the event of a temporary
> failure, you want to check whether this is part of a regular pattern
> of temporary failures, right?
Yes. As far as I can tell it _does_ do a fresh callout every time. It's
just that in the event of persistent 'temporary' failures I'd like to
notice that fact and give a permanent rejection instead of a temporary
one.
> Usually, a solution to this kind of requirement would be a little
> Perl script - invoked via ${run...} if you haven't got the Perl
> scripting interface in your exim build.
I could indeed do it with an external database, but that seems a little
strange since Exim already does almost every part of what's required;
logging the results of callouts into a database, with timestamps etc.
I'm half tempted to use an extra MTA as a staging post with 'defer_ok'
on the sender verification; forwarding to the machine which is currently
accepting mail. Then when a mail on the extra machine reaches its
maximum time on the queue and gets bounced, the bounce can go via the
ISP's outgoing smarthost, and they can deal with the noise; after all if
they'd let me point my MX records directly at my own machines in the
first place I wouldn't have this problem :)
--
dwmw2
