On Fri, 2005-12-23 at 09:54 +1100, Judd Howie wrote:
> Mail sent from an ip that does not resolve when a forward lookup is
> performed after EHLO gets blackholed immediately as per the below:
just to make it clear, this is not standard Exim behaviour.
> 2005-12-22 20:21:36 no IP address found for host bigaust.kasey.wfsystems.com
> (during SMTP connection from (skunkworks) [210.9.129.233])
> 2005-12-22 20:21:43 1EpMdo-0002rV-ET <= judd@???
> <mailto:judd@globalskunkworks.com> H=(skunkworks) [210.9.129.233] P=esmtpa
> A=fixed_login:judd@??? S=79499
> id=005301c606d9$1af71c70$0328a8c0@skunkworks
the "<mailto:" bit is puzzling, looks like the sender address hasn't
been set up correctly.
> 2005-12-22 20:21:43 1EpMdo-0002rV-ET => :blackhole: <judd@???>
> R=virtual_aliases
R=n means this message was handled by the router "n".
> So, I appreciate my sending hostname should probabaly resolve forward and I
> will get this solved shortly.
wouldn't hurt. as it is, you're sending the EHLO argument "skunkworks",
which is syntactically incorrect, and will be refused by for example my
servers. the EHLO name MUST be fully qualified, or an IP-address in
brackets.
> However, how do I disable this sender verication in Exim ?
sender verification is verification of the MAIL FROM address, not the
EHLO name.
> Also, these messages are just blackholing and there is no message back to
> the sender saying anything like "dear blah, this host does not accept mail
> from hosts that do not resolve on a forward lookup" How can I set this
> option?
change the :blackhole: to a :fail:.
> I have looked through my exim.conf for things like helo_try_verify_hosts = *
> etc but can't see anything earth shattering. I did find this:
> require verify = sender
> then commented it out, restarted exim and sent some test message again, no
> change. As such, I uncommented it and restarted again.
right. that should stay.
> Please see my exim.conf below, any help at all is very gratefully accepted.
doesn't using cPanel entitle you to technical support?
I must say they have really bad formatting of their configuration file,
it doesn't help readability at all.
http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/talks/2005-02-eximconf/paper.html#6.6.%20String%20expansions
http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/talks/2005-02-eximconf/paper.html#9.%20Appendices:%20configuration%20files%20and%20tables
> # primary_hostname =
as mentioned above, you should either fix your system so that
hostname(8) returns the fully qualified name, or you should set it
explicitly here.
> deliver_queue_load_max = 3
> auto_thaw = 6d
> ignore_bounce_errors_after = 7d
> timeout_frozen_after = 8d
you should get rid of auto_thaw, it causes bad behaviour in this
combination. see
http://bugzilla.cpanel.net/show_bug.cgi?id=2639
> helo_accept_junk_hosts = *
this is the reason your bogus HELO was accepted. this is however the
recommended setting, since user agents are chronically bad at getting
this right. so it's better to do the syntax checking manually when you
know it's not an authenticated user.
> smtp_enforce_sync = false
I'd recommend turning this on, it gets rid of quite a bit of junk mail
spewed out by badly written software. can't remember seeing any false
positives.
> virtual_aliases:
> driver = redirect
> allow_defer
> allow_fail
> data = ${if
> exists{/etc/valiases/$domain}{${lookup{*}lsearch{/etc/valiases/$domain}}}}
> file_transport = address_file
> group = mail
> pipe_transport = virtual_address_pipe
> domains = lsearch;/etc/localdomains
> retry_use_local_part
this is the matching router which expands to :blackhole:.
I'd recommend going through your configuration file from top to bottom,
read up what everything means, and remove settings and comments which
are redundant for your setup.
--
Kjetil T.
