SMTP ports, alternatives, authentication, and encryption
Data:
Tue, 17 Oct 2006 17:52:41 -0400
A:
OS/2 Wireless Users Mailing List <os2-wireless_users@2rosenthals.com>
There seems to be some confusion concerning SMTP (RFC 2821) Authenticated SMTP (SMTP-AUTH, RFC 2554), Encrypted SMTP (SMTP via SSL - Secure Sockets Layer) (RFC 2246), Encrypted Authentication, and SMTP via TLS (Transport Layer Security) (RFC 3207). Hopefully, this will be of some help, and if anyone has any corrections or RFC's to add, please feel free to chime in.
In addition, if folks here need an authenticated and/or encrypted SMTP/POP3/IMAP service, I have accounts available on my server for a nominal fee. The address will be at hautspot.com, and I can bounce returning mail to any account you choose, so you don't have to use my server for incoming if all you want is the ability to send on an alternative port. Please email me off-list for details: lgrosenthal at either hautspot.com or 2rosenthals.com (same box).
Anyway, here's what we've got:
Standard SMTP port is 25, whether authenticated or unauthenticated. It is common for ISP's to block access to third-party SMTP servers (i.e., port 25 transmissions outside the provider's network - not the venue's network, but the uplevel ISP) in a half-hearted attempt to block spam. Naturally, this only thwarts dumb (re)mailers, and doesn't stop real spammers who use reflection services on non-standard ports on remote servers.
SMTP may be encrypted and sent over SSL, and if so, usually an alternative port is used (as the server would listen on one port for unencrypted connections and a another for encrypted). This alternative port is traditionally 465.
SMTP may be authenticated using a username and password (most commonly). If sent in clear text, SMTP-AUTH uses port 25. the credentials may be hashed (encrypted), even though the following message is not. If the credentials are so encrypted, usually CRAM-MD5 is used as the challenge-response mechanism, though pothers (including Kerberos) may be used as the underlying cipher (SASL, or Simple Authentication and Security Layer) technology. The port is still typically 25 for such communications.
To avoid the need to run separate encrypted and unencrypted listeners on the server, TLS allows for the use of the STARTTLS command. When so configured, the email client will attempt to negotiate a secure socket with the server over the same port as standard SMTP (25). If the server responds in the affirmative (i.e., that it does indeed support TLS), the entire transaction - password and message - are then encrypted, assuming the balance of the negotiation is successful.
Non-standard ports may be used for any or all of the above, as long as both the server and the client are listening/sending on the same one. You just have to know what your provider supports, and what your mail client handles (not all mail clients support non-standard ports, SMTP-AUTH, SMTP over SSL or TLS).
If I missed anything, or someone has more questions on this, feel free to follow-up. I'll post a separate thread about my trials (and final tribulation) on finding a FREE public Wi-Fi service along route 80 on the way back east from Warpstock - in time to pay my mortgage online without penalty. Stay tuned!
--
Lewis
------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE
Rosenthal & Rosenthal, LLC
Accountants / Network Consultants
New York / Northern Virginia www.2rosenthals.com
eComStation Consultants www.ecomstation.com
Novell Users Int'l www.novell.com/openenterpriseserver
Need a managed Wi-Fi hotspot? www.hautspot.com
------------------------------------------------------------
torna alla lista