Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

relay via: "No MX found for domain" (FreeBSD) #544

Closed
fireglow opened this issue Feb 16, 2015 · 13 comments
Closed

relay via: "No MX found for domain" (FreeBSD) #544

fireglow opened this issue Feb 16, 2015 · 13 comments
Assignees
@poolpOrg
Labels
bug portable

Comments

@fireglow
Copy link

I'm seeing a "No MX found for domain" when using the relay via instruction.
The host www is a FreeBSD 10.1 jail, trying to talk to 10.0.110.5, which is another jail.

Error:
New session:

2015-02-16_20:44:51.67490 debug: smtp: new client on listener: 0x66df70
2015-02-16_20:44:51.67494 smtp-in: New session 23e3c0676c6f64c1 from host www [local]
2015-02-16_20:44:51.67614 debug: 0x8028cb000: end of message, msgflags=0x0000
2015-02-16_20:44:51.67635 smtp-in: Accepted message 0150edc4 on session 23e3c0676c6f64c1: from=<root@www>, to=<XXX@posteo.de>, size=162, ndest=1, proto=ESMTP
2015-02-16_20:44:51.67637 debug: scheduler: evp:0150edc4769cd31b scheduled (mta)
2015-02-16_20:44:51.67643 smtp-in: Closing session 23e3c0676c6f64c1
2015-02-16_20:44:51.67645 debug: smtp: 0x8028cb000: deleting session: done
2015-02-16_20:44:51.67652 debug: mta: received evp:0150edc4769cd31b for <XXX@posteo.de>
2015-02-16_20:44:51.67654 debug: mta: draining [relay:10.0.110.5,mx] refcount=1, ntask=1, nconnector=0, nconn=0
2015-02-16_20:44:51.67656 debug: mta: querying MX for [relay:10.0.110.5,mx]...
2015-02-16_20:44:51.67657 debug: mta: [relay:10.0.110.5,mx] waiting for MX
2015-02-16_20:44:51.67697 debug: Failed MX query for 10.0.110.5:
2015-02-16_20:44:51.67698 debug: mta: ... got mx (0x80281e120, 10.0.110.5, [relay:10.0.110.5,mx])
2015-02-16_20:44:51.67699 smtp-out: Failed to resolve MX for [relay:10.0.110.5,mx]: No MX found for domain
2015-02-16_20:44:51.67701 debug: mta: draining [relay:10.0.110.5,mx] refcount=1, ntask=1, nconnector=0, nconn=0
2015-02-16_20:44:51.67702 debug: mta_flush([relay:10.0.110.5,mx], 73, "No MX found for domain")
2015-02-16_20:44:51.67703 relay: TempFail for 0150edc4769cd31b: session=0000000000000000, from=<root@www>, to=<XXX@posteo.de>, rcpt=<->, source=-, relay=10.0.110.5, delay=0s, stat=No MX found for domain
2015-02-16_20:44:51.67704 debug: mta: freeing [relay:10.0.110.5,mx]
2015-02-16_20:44:51.67705 debug: mta: flush for 0150edc4769cd31b (-> XXX@posteo.de)

Starting smtpd:

2015-02-16_20:44:34.70868 debug: init ssl-tree
2015-02-16_20:44:34.70870 info: OpenSMTPD 5.4.4p1 starting
2015-02-16_20:44:34.70871 debug: bounce warning after 4h
2015-02-16_20:44:34.70873 debug: using "fs" queue backend
2015-02-16_20:44:34.70874 debug: using "ramqueue" scheduler backend
2015-02-16_20:44:34.70875 debug: using "ram" stat backend
2015-02-16_20:44:34.70876 info: startup [debug mode]
2015-02-16_20:44:34.70965 debug: init ssl-tree
2015-02-16_20:44:34.71020 debug: ca_engine_init: using RSAX engine support
2015-02-16_20:44:34.71061 debug: parent_send_config_ruleset: reloading
2015-02-16_20:44:34.71063 debug: parent_send_config: configuring pony process
2015-02-16_20:44:34.71065 debug: parent_send_config: configuring ca process
2015-02-16_20:44:34.71070 debug: smtp: listen on 10.0.112.1 port 25 flags 0x409 pki ""
2015-02-16_20:44:34.71074 debug: smtp: listen on IPv6:::1 port 25 flags 0x400 pki ""
2015-02-16_20:44:34.71077 debug: smtp: listen on 127.0.0.1 port 25 flags 0x400 pki ""
2015-02-16_20:44:34.71080 debug: smtp: will accept at most 235013 clients
2015-02-16_20:44:34.71081 debug: init private ssl-tree
2015-02-16_20:44:34.71621 debug: queue: done loading queue into scheduler
2015-02-16_20:44:35.71221 debug: smtpd: scanning offline queue...
2015-02-16_20:44:35.71229 debug: smtpd: offline scanning done

smtpd.conf:

listen on localhost
listen on 10.0.112.1 tls auth-optional

accept from local for any relay via smtp://10.0.110.5
accept for any relay via smtp://10.0.110.5

Versions:

dns/libasr 1.0.1_1
mail/opensmtpd 5.4.4_1,1

/etc/resolv.conf

nameserver 10.0.0.1
nameserver 62.210.16.6
nameserver 62.210.16.7

/etc/hosts

::1                     localhost localhost.my.domain
127.0.0.1               localhost localhost.my.domain

10.0.110.23     php php.www
10.0.112.1      www
10.0.110.7      db db.alpha
10.0.110.5      mail imap

What 10.0.110.5:25 is saying:

www# telnet 10.0.110.5 25
Trying 10.0.110.5...
Connected to mail.
Escape character is '^]'.
220 mail.firc.de ESMTP Postfix
^]
@curana
Copy link

curana commented Mar 6, 2015

I have a similar issue, FreeBSD 10.1 with same software version as you mentioned above.

I can't forward any email anymore. Always says "No MX found for domain", drill works fine showing me all details needed.

Any way to fix it?

Config mainly says

accept from any for domain <virtual_domains> virtual <virtual_aliases> forward-only

It worked until my recent update.

@ericfaurot
Copy link
Contributor

The problem is probably due to the AI_ADDRCONFIG used in getaddrinfo.
Could you show the output of ifconfig on the jail?

@fireglow
Copy link
Author

The lo1 iface, where the jails IPv4s are:

lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 10.0.112.1 netmask 0xffffff00 
        inet 10.0.112.2 netmask 0xffffff00 
        inet 10.0.110.23 netmask 0xffffff00 
        inet 10.0.112.3 netmask 0xffffff00 
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

@ericfaurot
Copy link
Contributor

So the problem is that the jail inet4 addresses are bound to a loopback device, and loopback devices are skipped in the AI_ADDRCONFIG iteration (per rfc).
Since they are non-local addresses, shouldn't they be set on a non-loopback interface, em or some virtual non-loopback iface?

@poolpOrg
Copy link
Member

PING ?

@m42v
Copy link

m42v commented Mar 25, 2015

Hi there.

First of all, thank you very much for this great piece of software and all your hard work!

I had the same issue with the "No MX found for domain" message, running OpenSMTPD inside a FreeBSD 10.1 jail and using a cloned loopback device as the jail network interface.
Since this kind of setup could not work, as eric pointed out, I created an ip address alias with a private ip address [10.0.0.X/32] on the internet facing real network interface. The pf firewall controls the NAT and redirect part for the jail as before. With the jail ip on the real interface I am now able to send mail without getting the above-mentioned message.
However, I'm not sure if this configuration is advisable, having a private ip address on a public interface, even if it's not addressable because of the pf firewall.

If there's a better way to run OpenSMTPD inside a jail, I'd really like to read about it.

@poolpOrg poolpOrg self-assigned this Apr 6, 2015
@poolpOrg
Copy link
Member

poolpOrg commented Apr 6, 2015

We discussed this but eric and I both think this is an environment issue, the daemon does what it is expected to do in a "normal" environment (that is consider the loopback interface like... a loopback interface).

The problem can be worked around by making changes to the environment and make it look a bit more like a real system, so this kind of comforts us in the idea that we should not throw code at the issue.

However, I'm not sure if this configuration is advisable, having a private ip address on a public interface, even if it's not addressable because of the pf firewall.

I don't really see the issue with that and it does seem considerably less risky than assigning a routable IP address to a loopback interface to be honest ;-)

@poolpOrg poolpOrg closed this as completed Apr 6, 2015
@kelexel
Copy link

kelexel commented Apr 30, 2015

Hi, as a FreeBSD 10.1 and FreeBSD jails user, let me pleas emphasis on the problem this creates.

Most, if not ALL FreeBSD Jail setup are based on a virtual loopback device where PF NATs every connections from / to the jails.

All daemons I've used so far, and I am sure I am not the only one in that case, lives happily by listening on a loopback device with a private IP (for instance "lo1" with IP "172.16.0.10")

Jails can of course share the host-os IP, but that's imo a bad idea.
Jails can only listen on one IP, meaning even if using the host-os IP, you can't bind the smtpd services to more than one IP
That's why we use PF and nat after all

But, I can't resign myself to do what is suggested above, which is assigning an IP from 172.16.0.0/24 (or any other private net) to my public interface (!!!!)

So please, re-consider the impact of this on real production FreeBSD servers.

@poolpOrg
Copy link
Member

Of course we'll reconsider, let's discuss this some more, the goal is not to prevent FreeBSD users from running it.
I'll be home in an hour and will look for a solution

@poolpOrg
Copy link
Member

Ok, issue has been discussed and I have suggested a "fix" that is not a hack, that is valid for non-jails and that should unbreak jails using loopback interfaces with non-loopback addresses.

The problem is not with OpenSMTPD but with libasr, therefore a new release of OpenSMTPD will not be required.

I'll publish a libasr snapshot today with the fix included, it would be great if you guys could test it and confirm it unbreaks your jails so that we can prepare a libasr release.

I'm re-opening the ticket until libasr has been released.

@poolpOrg poolpOrg reopened this Apr 30, 2015
@kelexel
Copy link

kelexel commented Apr 30, 2015

Hi, will test ASAP, thank you for re-opening

@poolpOrg
Copy link
Member

Here's the mail announcement for the snapshot in case you're not subscribed to the list:

http://thread.gmane.org/gmane.mail.opensmtpd.general/2569

Please give feedback ;-)

@poolpOrg
Copy link
Member

Ok, I've received several confirmations that this solves the issue.

I'll close the ticket now, the issue is not in opensmtpd but libasr, it has been fixed today and there will be a libasr release soon that will automagically unbreak jails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@poolpOrg poolpOrg

Labels
bug portable
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@fireglow @kelexel @curana @poolpOrg @ericfaurot @m42v