Re: cox.net being rejected redux

I’m being a bit lazy by not looking up your previous post, but I can’t see from this message how cox.net is involved? 

I’ll focus on the logs provided for now. The session below looks normal for a test session. 

> 10:01:00.713 4 SMTPI-002041([72.208.72.31]:46991) [192.168.69.246]:465
> <- [72.208.72.31]:46991 incoming connection(sma-inc.us <http://sma-inc.us/>)

Connection initiated

> 10:01:00.845 4 SMTPI-002041([72.208.72.31]:46991)
> TLS-002539(ECDHE_AES128_SHA256) connection accepted for DOMAIN(sma-inc.us <http://sma-inc.us/>)

TLS session for sam-inc.us successfully initiated

> 10:01:00.845 4 SMTPI-002041([72.208.72.31]:46991) rsp: 220 sma.com <http://sma.com/> ESMTP
> CommuniGate Pro 6.1.9 is glad to see you!

Mail server sends encrypted response to begin ESMTP handshake

> 
> 10:01:00.885 4 SMTPI-002041([72.208.72.31]:46991) cmd: EHLO [10.0.1.20]

Client sends EHLO command 

> 10:01:00.885 4 SMTPI-002041([72.208.72.31]) rsp: 250-sma-inc.us <http://250-sma-inc.us/> your
> name is not [10.0.1.20]\r\n250-DSN\r\n250-SIZE\r\n250-AUTH LOGIN PLAIN
> CRAM-MD5 DIGEST-MD5
> GSSAPI\r\n250-ETRN\r\n250-TURN\r\n250-ATRN\r\n250-NO-SOLICITING\r\n250-HELP\r\n250-PIPELINING\r\n250
> EHLO
> 

Server responds with available commands (2xx numbers mean that the server finds no problems so far.) 

> 10:01:00.922 4 SMTPI-002041([72.208.72.31]) cmd: QUIT

Client quits session

> 10:01:00.922 4 SMTPI-002041([72.208.72.31]) rsp: 221 sma-inc.us <http://sma-inc.us/>
> CommuniGate Pro SMTP closing connection
> 10:01:00.922 4 SMTPI-002041([72.208.72.31]) TLS connection is closing
> 10:01:00.922 4 SMTPI-002041([72.208.72.31]) closing connection
> 10:01:00.922 4 SMTPI-002041([72.208.72.31]) releasing stream


Session closed.


Typically instead of the QUIT command, the client would issue the requisite authentication command (AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5
GSSAPI) instead. Since this is on port 465, authentication is required to send. If this is actually the apple mail client, either is is simply running the connection doctor to test the connection, there is no actual mail to send to this server, so it QUITs the session, or the client is balking at some aspect of the connection. If the client is balking, I would speculate that it may not like the certificate that the server is providing. There should be something in the Mac console logs that informs you. You may need to import the certificate into your Apple keychain and explicitly trust it.