On Mon, 12 Mar 2012, Wietse Venema wrote: > Output from the "postconf -n" command is preferred here. If this > output differs from what you expect, then that it a possible > contributor to the problem.
Yes, already checked: high fidelity, no discrepancies. > TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail Thanks, I was unfamilliar with saslfinger. However, I'm not using Cyrus, but rather Dovecot. ...It didn't reveal any problems that I am aware of. It should be pointed out that the client I'm testing with is an Android phone less than three months old. It is configured to receive email through the same server, and that works, and sending: "login required", a valid username, security type of TLS, and port 25 - same as before this effort began. If I tell it the security type is "ssl", it won't let the configuration be saved and complains it can't access the server. Because it's a live system, it's hard to be sure what messages are related or unrelated during testing, so here's my best guess at what's one set of data per singular connect request when Android tries to check the connection - it's NOT trying to send an email, apparently: Mar 12 10:59:40 fs1 dovecot: auth(default): new auth connection: pid=304 Mar 12 10:59:40 fs1 postfix/smtpd[304]: connect from mcb0536d0.tmodns.net[208.54.5.203] Mar 12 10:59:40 fs1 dovecot: auth(default): client in: AUTH#0111#011LOGIN#011service=smtp#011nologin Mar 12 10:59:40 fs1 dovecot: auth(default): client out: CONT#0111#011<some encrypted data> Mar 12 10:59:40 fs1 dovecot: auth(default): client in: CONT<hidden> Mar 12 10:59:40 fs1 dovecot: auth(default): client out: CONT#0111#011<some encrypted data> Mar 12 10:59:40 fs1 dovecot: auth(default): client in: CONT<hidden> Mar 12 10:59:40 fs1 dovecot: auth(default): passwd-file(<username>): lookup: user=<username> file=/etc/cram-md5.pwd Mar 12 10:59:40 fs1 dovecot: auth(default): client out: OK#0111#011user=<username> Mar 12 10:59:40 fs1 postfix/smtpd[304]: disconnect from mcb0536d0.tmodns.net[208.54.5.203] Any further debugging ideas? Thanks again, Richard