[kwlug-disc] Testing a mail port

[B.S.]

(Skip to end for quick answer to current problem. Didn't think to do it until having written the diagnostic steps.)

[VERY LONG, APOLOGIES, HOPEFULLY USEFUL. TL;NR would not surprise me.]


It is both easier, and harder, than Khalid has said.

I agree with everything he has said.

However, most usually the problem is not a mail / smtp issue, but a routing / connectivity one.

telnet, encrypted or no, reveals whether you have a connectivity issue or not. Even encrypted, the other side is going to answer. Typing 'OK', 'EHLO', 'HELO', or anything should get you a response. Even if 'bad command'. Proving out connectivity. (REMEMBER: telnet frequently does not echo your characters back to you. You may not see your typing. You can turn local echo on. Point being, the other side is swallowing characters - something is catching them at the other end, the server is up on that port.)

Although you can dig deeper into smtp / what you can type, I find I do it so seldom that I don't retain the information. Really, once you have connectivity, you're likely to use your email client, web or local, to see if the other end is sane.

The problem comes when you can't prove out connectivity immediately. Then it's a routing, connectivity, or server up issue.

Thus ping and traceroute. Well, after dig and such tools as you noted as mxtools, to verify that the name (IP) you are trying to get to is the right one, and the server is up, at least for someone, somewhere. Thus your external connectivity checks (which were successful at mxtools), and dig for the MX record.

Aside from provider issues as this thread notes, the other wrinkles are any firewalls between you and the provider. USUALLY, though, this is more indicated by the ability to ping, and the inability to telnet. And you weren't able to even get this far. If you do, look for firewalls on the local machine (e.g. iptables-save, ufw status, pglcmd status, service ufw status, ps -eFH, and the like.) Even if you're unfamiliar with any of these, a quick peek should show you if anything might suspiciously be involved. Most of the time there is no local machine firewall (so isn't getting in the way), or something is pretty obviously paying attention (or not) to likely ports.

Thus it's also important to get as near to the provider's router as you can, and check the router for similarly obviously sticking its fingers in. For example, one thought I had with your thread is someone might have restricted outgoing 25 to your prior provider. With your provider change, I wondered if perhaps that might have been blocking you. (But your call to kwlug revealed too many others with the same results for that to be likely.)

Contacting the email, and your internet, provider is also a useful good step - as you did. Couple other thoughts for you when you have such conversations: (1) Can they ping you? [If you can't ping them, and they can't ping you, there is a backbone routing issue. Which is in THEIR interest to resolve - if it's happening to you, it's happening to others, and the sooner they resolve the issue, the sooner their phone stops ringing.] traceroute's from both ends is useful here - hopefully you can converge on an intermediate interlink. I've experienced this before - I was able to call our provider, get them to conference in all the interlink providers between me and them, and get the problem confirmed (immediately), and resolved within 2 days through that interlink's normal maintenance cycle. (BGP issue, IIRC.) All providers will have 24x7 emergency contacts - it is in THEIR interest to resolve issues ASAP. (2) Have the provider give you a known / valid / test port 25 (or whatever) to test against. Have them prove to you that they are not blocking such ports / your connectivity, and routing out works as expected. Which will also reveal if they are (and thus tell you) they are blocking such ports - giving you a definitive answer as to whether it should/n't work, and whether to continue chasing your tail or not.

I suspect there is a routing issue going on. It makes no sense that mxtools reveals the server as up, and nobody here can ping or tracroute to it. From multiple providers. Note: You don't have to be able to ping, or directly traceroute to the final destination. What you're really looking for is traceroute getting you near it. Preferably on the same network. In this case, nslookup mail.ufn.com -> 54.235.159.86, and dig -t MX kwflowers.com -> mail.ufn.com, so if traceroute got me to something 54.235.159.x, I would be pretty confident that there is no routing / connectivity issue going on. Might still be a server / firewall issue going on - but nobody has gotten that far, here.

Like I said in prior, don't forget that business accounts should have nothing blocked (except by request) {*}, and there are web sites that will let you ping, traceroute, and the like. Even a vpn or proxy in your back pocket will help you get outside your local provider to see if it's just your provider, the whole web, or just the server's provider. (You can also, and I forget the command, set up a listener/echoer somewhere else to see if a port is blocked. e.g. Had someone thought of it we could have set up something on port 25 for you, long enough for you to test connectivity on that port, and correlated with others as to whether or not success / failure was experienced across multiple providers.) e.g. If you can ssh home, for example, you could forward your 25 to a telnet session in your ssh, and typing 'hello' in your local telnet should show up there. You could also have ssh or openvpn listen on 25, and your local attempts to contact it should reveal invalid protocol, or some such. Using the native ports of either will confirm any routing issues. {*} Bear in mind, all providers have a best effort / YMMV policy, SLA or no. The problem is prying the specifics out of them - thus the phone call, and (2) / have them prove to you it works somewhere, anywhere.

That nobody here, across multiple providers, could ping, traceroute, or telnet with the details you were given is suspicious. And first, it's suspicious of connectivity (routing / backbone), not server, service, or port. i.e. traceroute, not telnet.

>From Bell (residential), traceroute hop 12 takes me to 216.182.224.57. 'whois 216.182.224.57' reveals somewhere within Amazon. From Rogers (business, I believe, so zero ports closed AFAIK), same, but at hop 21. From a VPN, same, at hop 19. This feels like an e-mail provider's internal provisioning issue - for them to talk to Amazon about. Something goofy is going on, if mxtools and some places can get through, but nobody here.

-----

And, finally, sorry for the very long diagnostic path description ... the quick answer ...


A quick google got me to http://www.yougetsignal.com/tools/open-ports/ - testing individual ports shows mail.ufn.com port 25 (smtp, per /etc/services) open, 587 (submission? - tls/smtp?) not. 143 (imap) is, 993 (imaps) is, 465 (smtps) isn't, 110 (pop) is.

- one quick takeaway from that is ... that server is responding to both incoming (e.g. smtp) and outgoing (e.g. pop). If you can read mail, your connectivity should also be good for sending - barring other issues. [But those issues won't be routing or connectivity issues.]

'telnet mail.ufn.com 143' reveals (cleartext) stuff, as does 110. 993 connects fine, but no text comes back. It doesn't disconnect immediately, which usually means it only responds to the right input. 110 and 143 work on all 3 providers I can get to, 993 on Bell and Rogers but not VPN.


Hint: http://tty.freeshell.org/ lets you create a free remote shell account. Useful at times like this.

There, 'telnet mail.ufn.com 25' reveals the expected clear text response we've been looking for.

Also, 'dig -t MX sdf.org' reveals mx.sdf.org, and there, 'telnet mx.sdf.org 25' also works. Thus if 'telnet mx.sdf.org 25' does not do the same locally, you have an outgoing port 25 problem. (As we all expected.)

These telnet's (25) [both mail.ufn.com and mx.sdf.org] failed for me on Bell and VPN, worked on Rogers (business). It would be useful if someone on Bell (business) could confirm same.


So, Joe you are in a pickle. This new provider will not work for you, except for the ugly solution you've already found.

It seems you have two choices:

(1) Get mail.ufn.com to give you an alternate port. It is not unusual for small clients as is likely their norm to have internet providers that do not allow port 25 out. Preferably they will fire up 465 (smtps) - 587 (tls/smtp) in a pinch.

(2) Get Bell to allow you to send out, at least to mail.ufn.com, on port 25. This will likely take a while, and probably involve some arm twisting. Your front line support won't be able to do it for you, so be prepared to be on hold for some time, and go through several people. I wouldn't be surprised if there is some form you have to fill out, and wait some days to be executed. If they'll do it at all.

There is a 3rd choice - if someone confirms Bell business service permits the telnet, switch to them, or to Rogers business. Or to another local provider. A number of them participate in kwlug. The downside there is they will be wholesaling Bell or Rogers, which is fine, but means another level to work through should any line problems occur. FWIW, I've never had any Bell or Rogers backbone problems. YMMV.)

(You could also set up a relay via VPN or even SDF, but that's likely more effort than your client is interested in, since you already have at least one solved solution in your hopper.)


HTH.

[There is a kwlug meeting night Q&A / workshop / round table / whiteboard, or something, in all this, somewhere.]



----- Original Message -----
> From: Khalid Baheyeldin <kb at 2bits.com>
> To: KWLUG discussion <kwlug-disc at kwlug.org>
> Sent: Friday, March 11, 2016 11:16 AM
> Subject: Re: [kwlug-disc] Testing a mail port
> 
> For dig, you don't need a tutorial. It is just a fancier nslookup. The
> man pages suffice here.
> 
> Learning the underlying DNS/Whois is what matters (e.g. A record is
> for hosts IPv4, AAAA is IPv6, MX is mail servers, TXT is SPF, CNAME is
> host aliased to other hosts, ...etc.)
> 
> As for nc, it is a generic network tool. The Digital Oceans tutorial is good
> 
> https://www.digitalocean.com/community/tutorials/how-to-use-netcat-to-establish-and-test-tcp-and-udp-connections-on-a-vps
> 
> And some tricks here
> 
> http://www.thegeekstuff.com/2012/04/nc-command-examples/
> 
> You do not need nc for basic mail server troubleshooting since telnet
> does the same thing. Again, what is important is learning the
> underlying mail server protocol is what matters, not the tool that you
> will be sending those command from.
> 
> The RFC for SMTP is here
> http://www.ietf.org/rfc/rfc2821.txt
> 
> As usual with RFCs it is dense and terse.
> 
> The gist of it is here:
> 
> http://www.tutorialspoint.com/internet_technologies/e_mail_protocols.htm
> 
> Remember that this is for plain text, which has been the case for
> decades, but now many servers use encrypted connections, so not as
> easy to simulate using telnet/nc.
> 
> On Thu, Mar 10, 2016 at 8:38 AM, Joseph Wennechuk
> <youcanreachmehere at hotmail.com> wrote:
>>  So through all of this I learned that I need to brush up on two commands
>>  that seem very useful. I need to hone my skills with nc, and dig. They both
>>  seem very useful. Has there been a presentation about these?
>>