Autor: Phil Pennock Data: Para: exim-users Assunto: Re: [exim] Delay when connecting to send mail
On 2008-02-05 at 12:25 +0000, Graeme Fowler wrote: > Given that the vast majority of people running an MUA wouldn't know what
> RFC1413 or the instructions for their firewall were if you printed them,
> rolled them up and hit them with the resulting nice bundle of paper,
> getting mass participation in the "play nicely and reject" scenario just
> isn't going to happen.
>
> I appreciate that the advice exists, but there's (usually) a much wider
> remit when providing an SMTP server than simply one person connecting to
> use it as an outbound relay. Setting the appropriate options in Exim's
> config makes it not do the lookup in the first place which, considering
> (a) the reduction in auth/ident services being run, and (b) the
> increasing number of devices which either block or reject ident calls
> outright, is the best place to do it. In my opinion.
Only just read this thread, sorry for the delay.
Personal stance: rfc1413 is there for the ability to include the data
when making a complaint to a remote site. Which doesn't happen so often
any more, with the sheer volume of abuse, but it's still occasionally
useful, where actually supported and used.
For submission service, where legitimate users are using their
mail-clients to inject mail and delays are user-visible and where
there's a high likelihood of firewalls or obnoxious host-based packet
filters, rfc1413 doesn't make sense. Require that senders be
authenticated instead.
For port 25, where you're tracing back inbound mail and where any MUA
using that port directly is misconfigured, rfc1413 is still occasionally
useful.
Hence I have:
rfc1413_hosts = ${if =={$received_port}{25}{*}{}}
Purely by coincidence, I only put that in last weekend, after this
thread. I was tracking down which delays were caused by a lack of
reverse DNS in the 2002::/16 IPv6 space and which were other causes and
I decided that this rfc1413_hosts setting was an appropriate tradeoff.
It was also most of the delay.
(I also fixed the lack of reverse DNS for my 2002::/16 address but
that's another issue)
Similarly, I also constrain the pre-HELO delay to be dependent upon
being port 25 with an ACL condition; I've had that for a bit longer and
the reasoning is much the same -- don't impose delays for something in
the user-interaction loop for message submission where I require
authentication for relaying anyway.