Re: sending email from localhost with JavaMail -- WEIRD prob w/servlet...
Dave Miller wrote:
Nigel Wade wrote:
Port 25 is normally used by MTAs for mail submission and transfer without
authentication. Authentication is normally done on port 587. Although it is
possible to offer authentication on port 25. There is a simple way to test it
out, telnet to port 25 and type "EHLO some.domain.name". The response will
tell
you what the MTA supports. If it doesn't include AUTH then AUTH won't work on
port 25. You should be able to try the same thing on port 587, port 587
should
not be encrypted at connection.
There is one situation where this won't work. That is if the mail server
doesn't
offer AUTH unless encryption is already established. This cannot be tested
using telnet because you won't be able to establish an SSL encrypted
connection
using TLS over telnet.
I can't test it from here because smtp.comcast.net does not respond on port
587
indicating it's probably an internal only submission system. I can't test
port
25 because that is blocked outgoing here. Also that host has no MX records
which mean it's unlikely to be an MTA and probably doesn't listen on port 25,
certainly not to the outside world anyway.
Most ISP's have gone to auth on submit to combat spam. They all block 25
from outside their networks for the same reason. We use a Comcast
competitor (Verizon) which uses auth on 25 intra network only.
The SMTP protocol doesn't differentiate between "submission" and "transport".
Submission is simply the originating source of the message. Transport/relay
uses exactly the same protocol, and the receiving MTA can't reliably determine
the difference between a mail client initiating a message and another MTA
relaying that message.
Many/most ISPs now differentiate mail submission by their own customers from
mail transport from other domains by using different hosts to perform these two
separate tasks. They will have configured their firewalls and authentication
schemes accordingly. The machines handling internal mail "submission" by their
own customers will almost certainly require authentication, and most likely
encryption, and not be accessible to the outside world.
I also don't have access to Comcast's network so this is only a guess
but they have something north of 15 million customers the vast majority
of whom are home users. It would be a tech support nightmare of the
living dead to try to migrate those users from 25 to 587 so I'm thinking
that they listen on 25 for customers physically connected to their network.
An ISP must allow incoming SMTP without authentication on port 25 to their mail
servers, or they won't be able to receive any incoming mail from other domains.
They can easily block their own customers from talking directly to their
Internet facing mail servers because they route all the traffic. To provide
those customers with port 25 submission the ISP only has to provide an internal
MTA, which may require auth. However, it's a different matter entirely to block
other ISPs customers.
They will probably implement SPF, or some other hackish attempt to circumvent
spam, but these generally either block legitimate mail or impose more strain
and overhead on other servers. They will almost certainly attempt to block
connection from a dynamic IP and will probably refuse any connection from an IP
which doesn't have correct rDNS and appropriate MX records.
My guess, and it's only a guess, is that the machine which the OP is attempting
to connect to is a Comcast internal mail submission system for Comcast
customers. This will most likely relay the mail via Comcast's mail servers
otherwise other ISPs with similar mail blocking schemes would not receive it.
Comcast do have a reputation for blocking mail from other ISPs due their
misconfiguration (or conspiracy if you prefer that theory).
--
Nigel Wade