Travis said:
Telnet started a session immediately.
Any other ideas?
Thank You!
So the IP name resolves to an IP address okay. And their mail server is
running okay. So far so good.
I don't know if your company is using AOL or is employing the same
tactic as AOL. AOL, for example, will refuse to accept e-mails if the
IP address for the sender doesn't have a reverse name lookup in their
DNS server. That is, some client comes in to connect to their mail
server and says it is "zebra" which means nothing to the recieving mail
server, or it might even include "mail.traviscrites.com" in the HELO or
EHLO command (which is just who the sender claims to be). The receiving
mail server will always know the IP address of whomever is connecting to
it. Say the IP address was 64.85.73.31. The receiving mail server
attempts a reverse DNS lookup on 64.85.73.31. If the IP name is
returned, the recieving mail server refuses the connection. They could
also check that the reverse name (m1.dnsix.com) for 64.85.72.31 be the
same as what was professed in the HELO command (traviscrites.com).
Because traviscrites.com resolves to 64.85.72.31 but a reverse name
lookup resolves to m1.dnsix.com it is possible the receiving mail server
might refuse the connection. I haven't seen this last scenario but is
possible, but I have seen the first scenario where a reverse name lookup
fails to the receiving mail server hangs up (after issuing an error
message).
Another possibility is that your company is filtering out domains in
blacklists to eliminate spam, and maybe your originating domain for your
e-mail (or a domain it gets relayed through) is on their blacklist.
I've seen companies that will reject e-mails from Hotmail, Yahoo, other
webmail providers, forwarding services like Bigfoot and others, so I
could not send them e-mails. They don't interrogate the content of the
e-mail to determine if it is spam. Instead they reject ALL e-mails
originating from those domains.
If the receiving SMTP server rejects an inbound e-mail to it, the sender
will get the rejection immediately (where "sender" is whomever is
connecting to the receiver's mail server). If you are using an e-mail
client to connect to an ISP's SMTP server which then will later connect
to the receiver's mail server, and if as you say the error is immediate
and not delayed, then the problem is between you and your ISP's SMTP
server. It's not like it accepted the e-mail and then sometime later
bounced back an e-mail reporting the delivery error. For example, if
the receiving mail server accepted your e-mail with a RCPT command
specifying a username on their domain, they usually don't bother doing
the lookup on that username until after they have accepted the e-mail
and then find out in a separate process that there was no such username,
and then they return the e-mail as a bounceback error message.
You might want to enable transport logging so you can watch the POP3 and
SMTP status and commands as they are issued between you e-mail client
and to whatever SMTP server you are connecting. Of course, I have been
guessing that you are connecting to an SMTP server. You don't mention
your mail environment to say if you are using your ISP's SMTP server, a
local Exchange or other server, and what is being used on the other end
(i.e., at the office).
