Ok. It is related to name resolution, but it is over my head. :-D It’s querying the mx record; then the a record for the mail server. But this is where it gets odd (at least for someone ignorant like me). Then the query prepends the mail server (mail.mailroute.net) to the hostname of the address. The resulting DNS query is for mail.mailroute.net.needfaith.org. This doesn’t exist and I am assuming to fails back onto the wildcard a record for needfaith.org.
I have no idea if I have some obscure misconfiguration (though I did try it on two fresh VM’s with FreeBSD 9.2 and 10.0-RC2). I reverted back to sendmail (ick ;-) ,and I was able to send an outbound email. Thanks, John Grasty On Dec 23, 2013, at 2:26 PM, John Grasty <[email protected]> wrote: > Ok. So apparently, I had not tested this specific case on either of my > machines. I spun up a fresh 9.2 virtual machine, and installed > opensmtpd-devel. This is with a different host, so odd routing issues should > not be the root cause. The MX lookup was wrong again. It pointed to the > 209.141.37.64 address. > > I scoured through my DNS, and that IP only shows up in an a record to > needfaith.org, an a record for *.needfaith.org, and an a record for > macarthur.needfaith.org. The MX for needfaith.org is correct. > > Thanks for the help, > John Grasty > > On Dec 23, 2013, at 1:05 PM, John Grasty <[email protected]> wrote: > >> Hi Gilles, >> >> Thanks for the response. I figured that y’all more need more info, but I was >> sick in bed and hoping there might have been a known issue. Once again, I’m >> bet it’s something on my side, but I wanted to be sure. I’m testing this on >> a KVM VM before I roll it on our production mail server, so to eliminate >> variables, I did a fresh install of FreeBSD 10, and I also tried the latest >> development snapshot in the FreeBSD ports tree (201312142054). Issue >> persists. Sending to gmail worked. However, I saw this issue again when >> sending to a different domain I own as well. Here’s some additional info: >> >> Failed destination email addresses and drill results (tested from the smtpd >> server machine) >> ———————— >> [email protected] >> >> drill needfaith.org mx >> ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25206 >> ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 >> ;; QUESTION SECTION: >> ;; needfaith.org. IN MX >> >> ;; ANSWER SECTION: >> needfaith.org. 300 IN MX 5 mail.mailroute.net. >> >> ;; AUTHORITY SECTION: >> needfaith.org. 83464 IN NS josh.ns.cloudflare.com. >> needfaith.org. 83464 IN NS emma.ns.cloudflare.com. >> >> ;; ADDITIONAL SECTION: >> emma.ns.cloudflare.com. 46456 IN A 173.245.58.112 >> emma.ns.cloudflare.com. 46456 IN AAAA >> 2400:cb00:2049:1::adf5:3a70 >> >> ;; Query time: 11 msec >> ;; SERVER: 205.185.112.69 >> >> >> [email protected] >> >> drill ggimissions.com mx >> ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 32280 >> ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 >> ;; QUESTION SECTION: >> ;; ggimissions.com. IN MX >> >> ;; ANSWER SECTION: >> ggimissions.com. 900 IN MX 5 mail.mailroute.net. >> >> ;; AUTHORITY SECTION: >> ggimissions.com. 130819 IN NS ns1.hover.com. >> ggimissions.com. 130819 IN NS ns2.hover.com. >> >> ;; ADDITIONAL SECTION: >> ns1.hover.com. 369 IN A 216.40.47.26 >> ns2.hover.com. 369 IN A 64.98.148.13 >> >> ;; Query time: 73 msec >> ;; SERVER: 205.185.112.68 >> >> drill mail.mailroute.net a >> ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 49037 >> ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> ;; QUESTION SECTION: >> ;; mail.mailroute.net. IN A >> >> ;; ANSWER SECTION: >> mail.mailroute.net. 51 IN A 199.89.0.201 >> >> ;; AUTHORITY SECTION: >> >> ;; ADDITIONAL SECTION: >> >> ;; Query time: 34 msec >> ;; SERVER: 8.8.8.8 >> >> (I use mail route for spam filtering. It receives, filters and relays on to >> my production smtpd server.) >> >> >> >> smtpd Server >> —————————— >> >> smtpd.conf: stock from sample file >> >> Hostname of server: keller.needfaith.org >> >> Relevant logs from smtpd -dv: >> >> debug: mta: received evp:a836407d3a2e6dd0 for <[email protected]> >> debug: mta: draining [relay:ggimissions.com] refcount=1, ntask=1, >> nconnector=0, nconn=0 >> debug: mta: querying MX for [relay:ggimissions.com]... >> debug: mta: [relay:ggimissions.com] waiting for MX >> smtp-in: Closing session a8246fb19493f682 >> debug: smtp: 0x28c9c000: deleting session: done >> debug: MXs for domain ggimissions.com: >> IPv6:2605:6400:2:fed5:22:443d:6325:4b75 preference 5 >> 209.141.37.64 preference 5 >> debug: mta: ... got mx (0x28c0a050, ggimissions.com, [relay:ggimissions.com]) >> >> Both IPv6 and IPv4 addresses are for another VM I test with. I’m going to do >> a fresh FreeBSD 9.2 install and see what happens. >> >> Thanks for the great piece of software, >> >> John Grasty >> >> >> >> On Dec 23, 2013, at 4:19 AM, Gilles Chehade <[email protected]> wrote: >> >>> On Mon, Dec 23, 2013 at 03:36:37AM -0500, John Grasty wrote: >>>> Hi, >>>> >>> >>> Hi, >>> >>> >>>> I love opensmtpd. >>>> >>> >>> So do I ;-) >>> >>> >>> >>>> I?m sure this error is my fault, but I can figure it out for the life of >>>> me. On a backup server, I have opensmtpd 5.4.1 with the sample config file >>>> listening on the localhost and relaying only local mail. This server?s >>>> hostname is subdomain.example.com. When I try to send an email from the >>>> command line to [email protected] (not the lack of the subdomain), smtpd >>>> fails. I have checked the logs, and it is returning the wrong MX record. >>>> It is showing in maillog the IP of another one of our servers. From the >>>> box running smtpd, I have verified by drill (the dig replacement) that the >>>> mx record is correct, yet opensmtpd is receiving an incorrect one. I am >>>> stuck. The same setup worked yesterday. Nothing has changed other than an >>>> upgrade from FreeBSD 9.2 to 10. >>>> >>>> I realize this may very likely be a FreeBSD problem (especially since it >>>> is DNS related and FreeBSD is a big change in that area), but I was hoping >>>> someone here may have some insight. >>>> >>> >>> You will need to show us more information to help troubleshooting. >>> >>> We can't rule out a problem on our side but retrieving wrong MX records >>> seems very unlikely. >>> >>> Can you show us output from dig/drill + logs from smtpd -dv as you relay >>> mail ? >>> >>> >>> -- >>> Gilles Chehade >>> >>> https://www.poolp.org @poolpOrg >> > -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
