Auteur: Tiago Botechia Silveira Date: À: exim-users Sujet: [exim] Smtp_defer DNS or SPF issues?
Hello, all!
First, I would like to say that if I am posting here is because I really tried
to find the answers by myself and looked into the reference material, such as
this list archives, the Exim Specification material, documentation, FAQ´s,
googled extensively and all of that.
Well, the fact is that I successfully configured Exim4 with relay for the users
with TLS. After a headache with avast! blocking tls (and don´t saying anything
about it!), all the clients can send e-mail using a secure connection.
I have no problems on receiving e-mail, both servers receive e-mail fine, quite
fast and reliable. However, the issue was then on the sending mail for external
networks capability. It was impossible!
Let me explain the networks characteristics for further analyses:
I manage two networks, which are sub networks of the department. They have just
one valid IP (150.162.55.xxx) address each, so I use a router for granting
access for the non-valid internal IP´s (192.168.0.0/24). These routers are both
coyote-like machines, using port-forward for the services running inside (web,
smtp, pop3, etc).
I think that exim configuration is ok (at least as far as I could learn about
it). I have two guesses about where the problem is.
1- DNS: I found out that the DNS does not indicate any MX entries for these
IP´s, just the regular one. Well, unfortunately, I do not manage the DNS server
over here, and the guy who manages the network department (150.162.55.xxx) is a
hard minded fellow, who likes to concentrate the power and the few knowledge he
has for himself, which means that itll be impossible to change it.
2- SPF complying: I was reading that some mx servers simply dont accept
e-mails coming from non-spf complaints servers. And as far as I know, I would
have to perform a change on the DNS entries for the IP´s (again, impossible)
These are some examples of the error logs, when sending messages:
. R=dnslookup T=remote_smtp defer (110): Connection timed out
The solution I found was using the department e-mail server (150.162.55.1) as a
smarthost, after I found out that the relay was obscenely open for internal
relay, without verifying even plain text usernames and passwords, which I think
is a risk because this network provides wi-fi connections using only a MAC
filter.
The problem is solved and the messages are being delivered, however, I do not
want to use smarthost for delivering messages. The more independent I am from
the department network servers, the best it is (and it also increases the hoops
of a message).
Do you think that it´s really a DNS / SPF issue? Because if it´s the case, I'll
try to change the DNS entries for the IP´s (like the advertise says, impossible
is nothing)
Otherwise, it´s a configuration problem that i couldn't find out.
Sorry for the big e-mail, but I intended to be clear about the issues I am
facing, and I also apologize for the poor English. I think a spring studying it
in Canterbury wasnt enough for me...
Sincerely,
Tiago Botechia
Process and Product Engineering Group
Production Engineering Department
Santa Catarina Federal University
Floripa SC - Brazil
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.