probably the best way to handle the "travelling user" need is with smtp-auth -- where the sending client authenticates.
look at/for the following lines in your sendmail.mc
dnl # The following causes sendmail to additionally listen to port 587 for dnl # mail from MUAs that authenticate. Roaming users who can't reach their dnl # preferred sendmail daemon due to port 25 being blocked or redirected find dnl # this useful.
the concept of temporarily adding a random/dynamic ipnumber isn't very good as it open a (admittedly probably small) window that might be able to be used by a spammer type should they come upon it.
Thank you very much for the help! I uncomment the line
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
but, I have a question: if outlook express does not use port 587, then what to do? How to make sure that if outlook express finds port 25 blocked, it will try port 587?
What about the other line
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
does that help if it is uncomment too?
Thanks!
Hongwei
Am Mi, den 30.11.2005 schrieb Hongwei Li um 21:32:
Thank you very much for the help! I uncomment the line
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
but, I have a question: if outlook express does not use port 587, then what to do? How to make sure that if outlook express finds port 25 blocked, it will try port 587?
You don't have to use SMTP AUTH through the submission port. It is common to offer AUTH on standard port 25.
What about the other line
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
does that help if it is uncomment too?
No need for that either. Even I think poorly designed MUAs like OE can not handle SMTPS.
Hongwei
Pleas read a howto for enabling SMTP AUTH running Sendmail, i.e. following
http://www.joreybump.com/code/howto/smtpauth.html
Just note that the location of the TLS certificates changes with FC4 release. So if you offer STARTTLS to secure insecure AUTH mechanisms LOGIN and PLAIN (Outlook and OE can't use secure MD5 mechanisms) - which is highly recommended to be secured - make sure you define the propers paths.
Alexander
Am Mi, den 30.11.2005 schrieb Hongwei Li um 21:32:
Thank you very much for the help! I uncomment the line
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
but, I have a question: if outlook express does not use port 587, then what to do? How to make sure that if outlook express finds port 25 blocked, it will try port 587?
You don't have to use SMTP AUTH through the submission port. It is common to offer AUTH on standard port 25.
What about the other line
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
does that help if it is uncomment too?
No need for that either. Even I think poorly designed MUAs like OE can not handle SMTPS.
Hongwei
Pleas read a howto for enabling SMTP AUTH running Sendmail, i.e. following
http://www.joreybump.com/code/howto/smtpauth.html
Just note that the location of the TLS certificates changes with FC4 release. So if you offer STARTTLS to secure insecure AUTH mechanisms LOGIN and PLAIN (Outlook and OE can't use secure MD5 mechanisms) - which is highly recommended to be secured - make sure you define the propers paths.
Alexander
Thank you for the information. I will read and try it.
Hongwei
Am Mi, den 30.11.2005 schrieb Hongwei Li um 21:32:
Thank you very much for the help! I uncomment the line
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
but, I have a question: if outlook express does not use port 587, then what to do? How to make sure that if outlook express finds port 25 blocked, it will try port 587?
You don't have to use SMTP AUTH through the submission port. It is common to offer AUTH on standard port 25.
What about the other line
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
does that help if it is uncomment too?
No need for that either. Even I think poorly designed MUAs like OE can not handle SMTPS.
Hongwei
Pleas read a howto for enabling SMTP AUTH running Sendmail, i.e. following
http://www.joreybump.com/code/howto/smtpauth.html
Just note that the location of the TLS certificates changes with FC4 release. So if you offer STARTTLS to secure insecure AUTH mechanisms LOGIN and PLAIN (Outlook and OE can't use secure MD5 mechanisms) - which is highly recommended to be secured - make sure you define the propers paths.
Alexander
A question: when I run make sendmail.pem, it asks:
Country Name (2 letter code) [GB]:
does GB mean "Great British"? I am in USA, so what should I enter? US?
Thanks!
Hongwei
Am Mi, den 30.11.2005 schrieb Hongwei Li um 22:22:
A question: when I run make sendmail.pem, it asks:
Country Name (2 letter code) [GB]:
does GB mean "Great British"? I am in USA, so what should I enter? US?
Hongwei
Yes, GB stands for Great Britain. I would have to choose DE for my German location. US is fine for your location. The information you enter there will be later displayable from the certificate. From technical view it can be from fantasy, though of course it is better to use real data.
Alexander
From: "Alexander Dalloz" ad+lists@uni-x.org ===8<--- original msg
What about the other line
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
does that help if it is uncomment too?
No need for that either. Even I think poorly designed MUAs like OE can not handle SMTPS.
===8<--- original msg
Um OE will handle several kinds of security including SMTPS if I believe its setup panels.
{^_^}
Am Do, den 01.12.2005 schrieb jdow um 1:26:
From: "Alexander Dalloz" ad+lists@uni-x.org
===8<--- original msg
What about the other line
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
does that help if it is uncomment too?
No need for that either. Even I think poorly designed MUAs like OE can not handle SMTPS.
===8<--- original msg
Um OE will handle several kinds of security including SMTPS if I believe its setup panels.
{^_^}
But OE for sure can't do STARTTLS on any port other than 25.
Alexander
Am Mi, den 30.11.2005 schrieb Hongwei Li um 21:32:
Hongwei
Pleas read a howto for enabling SMTP AUTH running Sendmail, i.e. following
http://www.joreybump.com/code/howto/smtpauth.html
Just note that the location of the TLS certificates changes with FC4 release. So if you offer STARTTLS to secure insecure AUTH mechanisms LOGIN and PLAIN (Outlook and OE can't use secure MD5 mechanisms) - which is highly recommended to be secured - make sure you define the propers paths.
Alexander
My system is fc3 linux, using sendmail-8.13.1-2 as email server. I followed the steps on that web page:
# cd /usr/share/ssl/certs/ # make sendmail.pem ... (I put our server's fully qualified domain name for the Common Name prompt)
# chkconfig saslauthd on # service saslauthd restart
# cd /etc/mail/ # vi sendmail.mc (changes:
define(`confAUTH_OPTIONS', `A p y')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
define(`confCACERT_PATH',`/usr/share/ssl/certs') define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem') define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')
define(`confLOG_LEVEL', `14')dnl )
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf # service sendmail restart
Then, I set a guest Outlook account by checking the boxes under Advanced Setting page:
Incoming server (POP3) -- This server requires an encrypted connection (SSL) -- the port changes from 110 to 995
Outgoing server (SMTP) -- This server requires an encrypted connection (SSL) -- the port number remains as 25
When I check the incoming emails, it shows the message about server certificate. I click Yes to continue, then it received all incoming emails. However, when I try to send email out, I first see the message: "An encrypted email connection has been detected...." I click OK, but failed sending email out. The error message is:
... error (0x800CCC7D): "Your outgoing (SMTP) server does not support SSL-encrypted connection....
The system maillog shows: ... Dec 1 10:07:52 morpheus sendmail[26574]: jB1G7ogu026574: Milter accept: message Dec 1 10:07:52 morpheus sendmail[26578]: jB1G7pt6026578: [128.252.85.103] did not issue MAIL/EXPN/VRFY/ETRN during connectio n to MTA Dec 1 10:07:52 morpheus sendmail[26602]: NOQUEUE: connect from [128.252.85.103] Dec 1 10:07:52 morpheus sendmail[26602]: AUTH: available mech=CRAM-MD5 DIGEST-MD5, allowed mech=LOGIN PLAIN Dec 1 10:07:52 morpheus sendmail[26602]: jB1G7q7s026602: Milter (greylist): init success to negotiate Dec 1 10:07:52 morpheus sendmail[26602]: jB1G7q7s026602: Milter: connect to filtersDec 1 10:07:52 morpheus sendmail[26602]: jB1G7q7s026602: milter=greylist, action=connect, continue Dec 1 10:07:52 morpheus sendmail[26602]: jB1G7q7s026602: [128.252.85.103] did not issue MAIL/EXPN/VRFY/ETRN during connectio n to MTA Dec 1 10:07:52 morpheus sendmail[26605]: NOQUEUE: connect from [128.252.85.103] Dec 1 10:07:52 morpheus sendmail[26605]: AUTH: available mech=CRAM-MD5 DIGEST-MD5, allowed mech=LOGIN PLAIN Dec 1 10:07:52 morpheus sendmail[26605]: jB1G7qFh026605: Milter (greylist): init success to negotiate Dec 1 10:07:52 morpheus sendmail[26605]: jB1G7qFh026605: Milter: connect to filtersDec 1 10:07:52 morpheus sendmail[26605]: jB1G7qFh026605: milter=greylist, action=connect, continue Dec 1 10:07:52 morpheus sendmail[26605]: jB1G7qFh026605: [128.252.85.103] did not issue MAIL/EXPN/VRFY/ETRN during connectio n to MTA ...
Did I miss something? Thanks for all help!
Hongwei
Am Do, den 01.12.2005 schrieb Hongwei Li um 17:13:
My system is fc3 linux, using sendmail-8.13.1-2 as email server.
Ok, so the path to the SSL certs is the old one, which changed first with FC4.
I followed the steps on that web page:
# cd /usr/share/ssl/certs/ # make sendmail.pem ... (I put our server's fully qualified domain name for the Common Name prompt)
Good.
# chkconfig saslauthd on # service saslauthd restart
The saslauthd restart wasn't necessary.
# cd /etc/mail/ # vi sendmail.mc (changes:
define(`confAUTH_OPTIONS', `A p y')dnl
Fine, that enables AUTH, forbids anonymous and enforces a secure connection requirement for weak auth mechanisms LOGIN and PLAIN.
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
Ok.
define(`confCACERT_PATH',`/usr/share/ssl/certs') define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem') define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')
Looks good.
define(`confLOG_LEVEL', `14')dnl
For debugging the changed log_level is fine.
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf # service sendmail restart
The service restart includes an automatic rebuilding of the .cf files if changes of the .mc files are detected.
Then, I set a guest Outlook account by checking the boxes under Advanced Setting page:
Incoming server (POP3) -- This server requires an encrypted connection (SSL) -- the port changes from 110 to 995
That has nothing to do with the MTA part. So if you want to provide secure POP3 connection - like through dovecot - that service has to be configured for that as well, and has to know about a certificate to use.
Outgoing server (SMTP) -- This server requires an encrypted connection (SSL) -- the port number remains as 25
Correct. Do not select "Secure Password Authentication" (SPA) if that is offered somewhere in the client's menu. Else authentication will fail.
When I check the incoming emails, it shows the message about server certificate. I click Yes to continue, then it received all incoming emails.
The client may show you that message always, unless you import the CA's certificate into your client.
However, when I try to send email out, I first see the message: "An encrypted email connection has been detected...." I click OK, but failed sending email out. The error message is:
... error (0x800CCC7D): "Your outgoing (SMTP) server does not support SSL-encrypted connection....
Hm, i may be advised to restart Outlook / OE. You too should clear the SSL cache. Because of the integration of different applications you reach this option through Internet Exploder options menu. A different reason for that problem can be an anti-virus scanner running in background. Well known for this broken (since years) and probably never fixed behaviour is Norton Antivirus. Of course, before trying any "tricks", be sure you have the latest version of OE on your system.
The system maillog shows: ... Dec 1 10:07:52 morpheus sendmail[26574]: jB1G7ogu026574: Milter accept: message Dec 1 10:07:52 morpheus sendmail[26578]: jB1G7pt6026578: [128.252.85.103] did not issue MAIL/EXPN/VRFY/ETRN during connectio n to MTA Dec 1 10:07:52 morpheus sendmail[26602]: NOQUEUE: connect from [128.252.85.103] Dec 1 10:07:52 morpheus sendmail[26602]: AUTH: available mech=CRAM-MD5 DIGEST-MD5, allowed mech=LOGIN PLAIN
That does not look correct. The both MD5 mechs shouldn't been listed due to your configuration.
Did I miss something? Thanks for all help!
Hongwei
You can debug the situation by directly accessing the Sendmail MTA on command line:
telnet <sendmail host> 25 ehlo foo.bar -> server will print out some info, interesting is the part behind "250-AUTH": it shouldn't list anything now.
Then run in SSL mode:
openssl s_client -connect <sendmail host>:25 -starttls smtp
That should print out a lot of lines which tell you something about encryption going on. It finally will give you again the greet message of Sendmail. Then enter again:
ehlo foo.bar
... and watch out for an AUTH line. It now must offer you "250-AUTH LOGIN PLAIN". You end the session by entering QUIT.
If things aren't fixed now, then run "service sendmail restart" and watch the /var/log/maillog for any errors / problems reported during daemon startup.
Alexander
Am Do, den 01.12.2005 schrieb Hongwei Li um 17:13:
My system is fc3 linux, using sendmail-8.13.1-2 as email server.
Ok, so the path to the SSL certs is the old one, which changed first with FC4.
I followed the steps on that web page:
# cd /usr/share/ssl/certs/ # make sendmail.pem ... (I put our server's fully qualified domain name for the Common Name prompt)
Good.
# chkconfig saslauthd on # service saslauthd restart
The saslauthd restart wasn't necessary.
# cd /etc/mail/ # vi sendmail.mc (changes:
define(`confAUTH_OPTIONS', `A p y')dnl
Fine, that enables AUTH, forbids anonymous and enforces a secure connection requirement for weak auth mechanisms LOGIN and PLAIN.
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
Ok.
define(`confCACERT_PATH',`/usr/share/ssl/certs') define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem') define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')
Looks good.
define(`confLOG_LEVEL', `14')dnl
For debugging the changed log_level is fine.
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf # service sendmail restart
The service restart includes an automatic rebuilding of the .cf files if changes of the .mc files are detected.
Then, I set a guest Outlook account by checking the boxes under Advanced Setting page:
Incoming server (POP3) -- This server requires an encrypted connection (SSL) -- the port changes from 110 to 995
That has nothing to do with the MTA part. So if you want to provide secure POP3 connection - like through dovecot - that service has to be configured for that as well, and has to know about a certificate to use.
-- yes, I have enabled secure pop3 through dovecot and the port 995 is opened in iptable.
Outgoing server (SMTP) -- This server requires an encrypted connection (SSL) -- the port number remains as 25
Correct. Do not select "Secure Password Authentication" (SPA) if that is offered somewhere in the client's menu. Else authentication will fail.
-- no, I did not select this.
When I check the incoming emails, it shows the message about server certificate. I click Yes to continue, then it received all incoming emails.
The client may show you that message always, unless you import the CA's certificate into your client.
However, when I try to send email out, I first see the message: "An encrypted email connection has been detected...." I click OK, but failed sending email out. The error message is:
... error (0x800CCC7D): "Your outgoing (SMTP) server does not support SSL-encrypted connection....
Hm, i may be advised to restart Outlook / OE. You too should clear the SSL cache. Because of the integration of different applications you reach this option through Internet Exploder options menu. A different reason for that problem can be an anti-virus scanner running in background. Well known for this broken (since years) and probably never fixed behaviour is Norton Antivirus. Of course, before trying any "tricks", be sure you have the latest version of OE on your system.
The system maillog shows: ... Dec 1 10:07:52 morpheus sendmail[26574]: jB1G7ogu026574: Milter accept: message Dec 1 10:07:52 morpheus sendmail[26578]: jB1G7pt6026578: [128.252.85.103] did not issue MAIL/EXPN/VRFY/ETRN during connectio n to MTA Dec 1 10:07:52 morpheus sendmail[26602]: NOQUEUE: connect from [128.252.85.103] Dec 1 10:07:52 morpheus sendmail[26602]: AUTH: available mech=CRAM-MD5 DIGEST-MD5, allowed mech=LOGIN PLAIN
That does not look correct. The both MD5 mechs shouldn't been listed due to your configuration.
-- where sohuld I change? I checked sendmail.mc, but could not find which line to change.
Did I miss something? Thanks for all help!
Hongwei
You can debug the situation by directly accessing the Sendmail MTA on command line:
telnet <sendmail host> 25 ehlo foo.bar -> server will print out some info, interesting is the part behind "250-AUTH": it shouldn't list anything now.
Then run in SSL mode:
openssl s_client -connect <sendmail host>:25 -starttls smtp
That should print out a lot of lines which tell you something about encryption going on. It finally will give you again the greet message of Sendmail. Then enter again:
ehlo foo.bar
... and watch out for an AUTH line. It now must offer you "250-AUTH LOGIN PLAIN". You end the session by entering QUIT.
If things aren't fixed now, then run "service sendmail restart" and watch the /var/log/maillog for any errors / problems reported during daemon startup.
Alexander
Below is what I did and got.
# telnet morpheus.wustl.edu 25 Trying 128.252.85.129... Connected to morpheus.wustl.edu (128.252.85.129). Escape character is '^]'. 220 morpheus.wustl.edu ESMTP Sendmail 8.13.1/8.13.1; Thu, 1 Dec 2005 11:38:28 -0600 ehlo foo.bar 250-morpheus.wustl.edu Hello morpheus.wustl.edu [128.252.85.129], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 morpheus.wustl.edu closing connection Connection closed by foreign host. #
# openssl s_client -connect morpheus.wustl.edu:25 -starttls smtp CONNECTED(00000003) depth=0 /C=US/ST=Missouri/L=Saint Louis/O=Washington University/OU=Research Unit/CN=morpheus.wustl.edu/emailAddress=root@morpheus.wustl.edu verify error:num=18:self signed certificate verify return:1 depth=0 /C=US/ST=Missouri/L=Saint Louis/O=Washington University/OU=Research Unit/CN=morpheus.wustl.edu/emailAddress=root@morpheus.wustl.edu verify return:1 --- Certificate chain 0 s:/C=US/ST=Missouri/L=Saint Louis/O=Washington University/OU=Research Unit/CN=morpheus.wustl.edu/emailAddress=root@morpheus.wustl.edu i:/C=US/ST=Missouri/L=Saint Louis/O=Washington University/OU=Research Unit/CN=morpheus.wustl.edu/emailAddress=root@morpheus.wustl.edu --- Server certificate -----BEGIN CERTIFICATE----- MIID9DCCA12gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBszELMAkGA1UEBhMCVVMx ... -----END CERTIFICATE----- subject=/C=US/ST=Missouri/L=Saint Louis/O=Washington University/OU=Research Unit/CN=morpheus.wustl.edu/emailAddress=root@morp heus.wustl.edu issuer=/C=US/ST=Missouri/L=Saint Louis/O=Washington University/OU=Research Unit/CN=morpheus.wustl.edu/emailAddress=root@morpheus.wustl.edu ---Acceptable client certificate CA names /C=US/ST=Utah/L=Salt Lake City/O=Xcert EZ by DST/CN=Xcert EZ by DST/emailAddress=ca@digsigtrust.com /C=US/O=Digital Signature Trust Co./OU=DST (ANX Network) CA /C=US/O=American Express Company, Inc./OU=American Express Technologies/CN=American Express Certificate Authority ... /C=US/ST=North Carolina/L=Raleigh/O=Red Hat, Inc./OU=Red Hat Network/CN=RHN Certificate Authority/emailAddress=rhn-noc@redhat.com---SSL handshake has read 10759 bytes and written 298 bytes---New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHAServer public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 74250E3AB88FE415C19840AA00EA329F8405503621B7234B3643156814DDE944 Session-ID-ctx: Master-Key: B82FCB44A32F94E5E842EB2D6DA844F17CFD5A5E8A1A6E97F634D80E38F072B57025F11C4D5D3E2839051E57DAF8FA01 Key-Arg : None Krb5 Principal: None Start Time: 1133458889 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- 220 morpheus.wustl.edu ESMTP Sendmail 8.13.1/8.13.1; Thu, 1 Dec 2005 11:41:29 -0600 ehlo foo.bar 250-morpheus.wustl.edu Hello morpheus.wustl.edu [128.252.85.129], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-DELIVERBY 250 HELP quit 221 2.0.0 morpheus.wustl.edu closing connection closed #
I cleaned SSL cache, cookies, etc. restart Outlook / OE, test it on 3 different computers, still got the same error.
Also, when I try OE, the error message is:
Unable to establish SSL connection with the server. Account "morpheus", Server: "morpheus.wustl.edu', Protocol: SMTP, Server Response: '454 TLS not available due to temporary reason', Port: 25, Secure(SSL): Yes, Server Error: 454, Error Number: 0x800CCC7F
Could you give me more help? Thanks!
Hongwei
Am Do, den 01.12.2005 schrieb Hongwei Li um 20:45:
Dec 1 10:07:52 morpheus sendmail[26602]: AUTH: available mech=CRAM-MD5 DIGEST-MD5, allowed mech=LOGIN PLAIN
That does not look correct. The both MD5 mechs shouldn't been listed due to your configuration.
-- where sohuld I change? I checked sendmail.mc, but could not find which line to change.
No, your sendmail.mc changes were correct, following the tutorial on the website I gave you the URL of. At least if you didn't just append the settings at the bottom but made the changes inline, where you found commented entries.
Below is what I did and got.
# telnet morpheus.wustl.edu 25 Trying 128.252.85.129... Connected to morpheus.wustl.edu (128.252.85.129). Escape character is '^]'. 220 morpheus.wustl.edu ESMTP Sendmail 8.13.1/8.13.1; Thu, 1 Dec 2005 11:38:28 -0600 ehlo foo.bar 250-morpheus.wustl.edu Hello morpheus.wustl.edu [128.252.85.129], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 morpheus.wustl.edu closing connection Connection closed by foreign host.
That is exactly what is to be expected: STARTTLS is offered, but no AUTH - just because you told Sendmail to only offer LOGIN and PLAIN AUTH mechs when the connection is safe (=encrypted).
# openssl s_client -connect morpheus.wustl.edu:25 -starttls smtp CONNECTED(00000003)
[ certificate data stripped ]
Verify return code: 18 (self signed certificate)
220 morpheus.wustl.edu ESMTP Sendmail 8.13.1/8.13.1; Thu, 1 Dec 2005 11:41:29 -0600
Good up to this point. The STARTTLS session was successfully established and Sendmail greats you.
ehlo foo.bar 250-morpheus.wustl.edu Hello morpheus.wustl.edu [128.252.85.129], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN
Now with the encrypted connection Sendmail allows you to AUTH using either LOGIN or PLAIN.
250-DELIVERBY 250 HELP quit 221 2.0.0 morpheus.wustl.edu closing connection closed #
I cleaned SSL cache, cookies, etc. restart Outlook / OE, test it on 3 different computers, still got the same error.
Also, when I try OE, the error message is:
Unable to establish SSL connection with the server. Account "morpheus", Server: "morpheus.wustl.edu', Protocol: SMTP, Server Response: '454 TLS not available due to temporary reason', Port: 25, Secure(SSL): Yes, Server Error: 454, Error Number: 0x800CCC7F
I would be it is a client problem. To evaluate simply go on with testing where you stopped.
Hongwei
When you made the hand established TLS connection and then entered "EHLO foo.bar", go on and AUTH yourself. To do this you need to base64 encode your username and password. You can do this with a Perl 1-liner:
perl -MMIME::Base64 -e 'print encode_base64("user\0user\0password");'
That will print out a string which you have to enter following way (after initial EHLO):
AUTH PLAIN dXNlcgB1c2VyAHBhc3N3b3Jk
That must be answered by Sendmail with a authentication success message. If you hand auth using LOGIN, you enter "AUTH LOGIN", will get back a base64 string which decodes as the question which user shall auth, you enter the base64 encoded username, then Sendmail will ask in base64 form for your password, which you have to enter too in base64 encoding. Finally a success message must follow.
I am sure these test will be successful as the initial test trying to establish a STARTTLS session already was successful. So your problem is client based. Check for firewalling and anti-virus scanners (outbound mail scanning), as I told you before. The issue (especially Norton's thing) is well known and an ongoing pain. You will find many hits and references to this through google. I.e.
http://www.cs.wisc.edu/csl/old-doc/info/smtp-auth/
If you face other cryptic OE error codes, use google too or directly go to
http://support.microsoft.com/default.aspx?scid=kb;en-us;208814
Alexander
Am Do, den 01.12.2005 schrieb Hongwei Li um 20:45:
When you made the hand established TLS connection and then entered "EHLO foo.bar", go on and AUTH yourself. To do this you need to base64 encode your username and password. You can do this with a Perl 1-liner:
perl -MMIME::Base64 -e 'print encode_base64("user\0user\0password");'
That will print out a string which you have to enter following way (after initial EHLO):
AUTH PLAIN dXNlcgB1c2VyAHBhc3N3b3Jk
That must be answered by Sendmail with a authentication success message. If you hand auth using LOGIN, you enter "AUTH LOGIN", will get back a base64 string which decodes as the question which user shall auth, you enter the base64 encoded username, then Sendmail will ask in base64 form for your password, which you have to enter too in base64 encoding. Finally a success message must follow.
I am sure these test will be successful as the initial test trying to establish a STARTTLS session already was successful. So your problem is client based. Check for firewalling and anti-virus scanners (outbound mail scanning), as I told you before. The issue (especially Norton's thing) is well known and an ongoing pain. You will find many hits and references to this through google. I.e.
I tested, but got:
# perl -MMIME::Base64 -e 'print encode_base64("user\0user\0password");' dXNlcgB1c2VyAHBhc3N3b3Jk
(after # openssl s_client -connect morpheus.wustl.edu:25 -starttls smtp ... 220 morpheus.wustl.edu ESMTP Sendmail 8.13.1/8.13.1; Thu, 1 Dec 2005 14:52:41 -0600 ehlo foo.bar 250-morpheus.wustl.edu Hello morpheus.wustl.edu [128.252.85.129], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-DELIVERBY 250 HELP AUTH PLAIN dXNlcgB1c2VyAHBhc3N3b3Jk 535 5.7.0 authentication failed AUTH LOGIN dXNlcgB1c2VyAHBhc3N3b3Jk 334 UGFzc3dvcmQ6
(if I press Enter, it shows:) 535 5.7.0 authentication failed
quit
Did I do something wrong?
Thanks!
Hongwei
Am Do, den 01.12.2005 schrieb Hongwei Li um 20:45:
When you made the hand established TLS connection and then entered "EHLO foo.bar", go on and AUTH yourself. To do this you need to base64 encode your username and password. You can do this with a Perl 1-liner:
perl -MMIME::Base64 -e 'print encode_base64("user\0user\0password");'
That will print out a string which you have to enter following way (after initial EHLO):
AUTH PLAIN dXNlcgB1c2VyAHBhc3N3b3Jk
That must be answered by Sendmail with a authentication success message. If you hand auth using LOGIN, you enter "AUTH LOGIN", will get back a base64 string which decodes as the question which user shall auth, you enter the base64 encoded username, then Sendmail will ask in base64 form for your password, which you have to enter too in base64 encoding. Finally a success message must follow.
I am sure these test will be successful as the initial test trying to establish a STARTTLS session already was successful. So your problem is client based. Check for firewalling and anti-virus scanners (outbound mail scanning), as I told you before. The issue (especially Norton's thing) is well known and an ongoing pain. You will find many hits and references to this through google. I.e.
I tested, but got:
# perl -MMIME::Base64 -e 'print encode_base64("user\0user\0password");' dXNlcgB1c2VyAHBhc3N3b3Jk
(after # openssl s_client -connect morpheus.wustl.edu:25 -starttls smtp ... 220 morpheus.wustl.edu ESMTP Sendmail 8.13.1/8.13.1; Thu, 1 Dec 2005 14:52:41 -0600 ehlo foo.bar 250-morpheus.wustl.edu Hello morpheus.wustl.edu [128.252.85.129], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-DELIVERBY 250 HELP AUTH PLAIN dXNlcgB1c2VyAHBhc3N3b3Jk 535 5.7.0 authentication failed AUTH LOGIN dXNlcgB1c2VyAHBhc3N3b3Jk 334 UGFzc3dvcmQ6
(if I press Enter, it shows:) 535 5.7.0 authentication failed
quit
Did I do something wrong?
Thanks!
Hongwei
--
If I disable Norton Antivirus, then the OE works. But, most users would not like to disable norton antivirus, how to work around this? especially, we have Symantec Antivirus as managed by the shcool, it is not easy to explain to everybody how to disable it when sending emails out, then enable it after finished.
Thanks!
Hongwei
Am Do, den 01.12.2005 schrieb Hongwei Li um 22:11:
If I disable Norton Antivirus, then the OE works. But, most users would not like to disable norton antivirus, how to work around this? especially, we have Symantec Antivirus as managed by the shcool, it is not easy to explain to everybody how to disable it when sending emails out, then enable it after finished.
Hongwei
Well, when did I first mention Norton Antivirus to be a candidate for disturbing the TLS communication, 3 hours ago? ;) Write a webpage with screenshots where users can easily follow the steps to disable the outbound mail scanning. If the software is centrally delivered, then change the configuration policy. [I don't think complaining at Norton about the issue will ever change anything.]
Alexander
Well, when did I first mention Norton Antivirus to be a candidate for disturbing the TLS communication, 3 hours ago? ;) Write a webpage with screenshots where users can easily follow the steps to disable the outbound mail scanning. If the software is centrally delivered, then change the configuration policy. [I don't think complaining at Norton about the issue will ever change anything.]
Alexander
Thank you for all the help!
Hongwei
Am Do, den 01.12.2005 schrieb Hongwei Li um 22:00:
I tested, but got:
# perl -MMIME::Base64 -e 'print encode_base64("user\0user\0password");' dXNlcgB1c2VyAHBhc3N3b3Jk
You faced that this was an example I gave? Of course your user isn't named "user", but maybe "lih" and has a password which isn't password (at least I hope so).
(after # openssl s_client -connect morpheus.wustl.edu:25 -starttls smtp ... 220 morpheus.wustl.edu ESMTP Sendmail 8.13.1/8.13.1; Thu, 1 Dec 2005 14:52:41 -0600 ehlo foo.bar 250-morpheus.wustl.edu Hello morpheus.wustl.edu [128.252.85.129], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-DELIVERBY 250 HELP AUTH PLAIN dXNlcgB1c2VyAHBhc3N3b3Jk 535 5.7.0 authentication failed
AUTH PLAIN syntax is used correctly.
AUTH LOGIN dXNlcgB1c2VyAHBhc3N3b3Jk 334 UGFzc3dvcmQ6
No, as explained AUTH LOGIN works differently.
C: AUTH LOGIN S: give me your username C: user S: give me your password C: password
C=client, S=server - all input and output during the auth handshake is base64 encoded.
(if I press Enter, it shows:) 535 5.7.0 authentication failed
quit
Did I do something wrong?
Hongwei
Alexander
I am sure these test will be successful as the initial test trying to establish a STARTTLS session already was successful. So your problem is client based. Check for firewalling and anti-virus scanners (outbound mail scanning), as I told you before. The issue (especially Norton's thing) is well known and an ongoing pain. You will find many hits and references to this through google. I.e.
http://www.cs.wisc.edu/csl/old-doc/info/smtp-auth/
Alexander
Below is quoted from the above web site:
"NOTE: If your Internet Service Provider blocks SMTP traffic using Port 25, you must configure your email client to use Port 587 instead. Some ISPs block Port 25 in an attempt to reduce spam and viruses. The CSL has made Port 587 (a reserved port for email message submission) available for authenticated SMTP. Please see configuration information for your specific email client below..."
The Symantec Antivirus checks port 25 for outgoing emails. So, if we could set port 587 for smtp on the server side, then it may work with symentac antivirus. Is it true? If yes, how to set the port 587 on the server side for smtp? Will that work anyway?
Thanks!
Hongwei
Am Do, den 01.12.2005 schrieb Hongwei Li um 23:07:
Below is quoted from the above web site:
"NOTE: If your Internet Service Provider blocks SMTP traffic using Port 25, you must configure your email client to use Port 587 instead. Some ISPs block Port 25 in an attempt to reduce spam and viruses. The CSL has made Port 587 (a reserved port for email message submission) available for authenticated SMTP. Please see configuration information for your specific email client below..."
The Symantec Antivirus checks port 25 for outgoing emails. So, if we could set port 587 for smtp on the server side, then it may work with symentac antivirus. Is it true? If yes, how to set the port 587 on the server side for smtp? Will that work anyway?
Hongwei
The Norton Antivirus application which is a desktop application AFAIK does not distinguish between the ports. But maybe that changed meanwhile. Just test it.
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
in sendmail.mc enables the submission agent with authentication enforcement. I guess you have
FEATURE(`no_default_msa',`dnl')dnl
set - recommended - and thus the normal (not requiring auth) MSA disabled. Setting the DAEMON_OPTIONS for the MSA be sure you have too
DAEMON_OPTIONS(`Port=smtp,Name=MTA')dnl
set - either this way or when restricting to specific IP, then several lines of that with IP specification where 1 is for 127.0.0.1.
Alexander
Am Do, den 01.12.2005 schrieb Hongwei Li um 23:07:
The Norton Antivirus application which is a desktop application AFAIK does not distinguish between the ports. But maybe that changed meanwhile. Just test it.
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
in sendmail.mc enables the submission agent with authentication enforcement. I guess you have
FEATURE(`no_default_msa',`dnl')dnl
set - recommended - and thus the normal (not requiring auth) MSA disabled. Setting the DAEMON_OPTIONS for the MSA be sure you have too
DAEMON_OPTIONS(`Port=smtp,Name=MTA')dnl
set - either this way or when restricting to specific IP, then several lines of that with IP specification where 1 is for 127.0.0.1.
Alexander
After adding:
DAEMON_OPTIONS(`Port=smtp,Name=MTA')dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
in sendmail.mc, run m4 and restart sendmail, I tested OE and Outlook (set outgoing port 587 and use ssl connection) in many different ways on different computers. I found that with Norton Antivirus enabled, Outlook (my version is 2003) works well, but OE (version 6) does not work -- cannot send emails out, no matter pop3 or imap is used in OE or Outlook. Any more idea or suggestion?
Thanks!
Hongwei
Am Fr, den 02.12.2005 schrieb Hongwei Li um 22:45:
After adding:
DAEMON_OPTIONS(`Port=smtp,Name=MTA')dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
in sendmail.mc, run m4 and restart sendmail, I tested OE and Outlook (set outgoing port 587 and use ssl connection) in many different ways on different computers. I found that with Norton Antivirus enabled, Outlook (my version is 2003) works well, but OE (version 6) does not work -- cannot send emails out, no matter pop3 or imap is used in OE or Outlook. Any more idea or suggestion?
Hongwei
I feared that would be the case. I would move anti-virus testing from clients to the mail server - at least for outgoing mail and especially for those roaming users. Let them switch off outbound mail checking by Norton Antivirus and on your Sendmail mail server install clamav-milter to let it check for virus'. Another good idea is to kick and ban such horrible software like OE. There are much better 'free' alternates like Thunderbird.
Alexander
I feared that would be the case. I would move anti-virus testing from clients to the mail server - at least for outgoing mail and especially for those roaming users. Let them switch off outbound mail checking by Norton Antivirus and on your Sendmail mail server install clamav-milter to let it check for virus'. Another good idea is to kick and ban such horrible software like OE. There are much better 'free' alternates like Thunderbird.
Alexander
Thanks for all of your help and suggestion! My linux server has clamav installed and it works well. However, some users still prefer their local antivirus agent. Probably, that is the case and what I can do.
Hongwei
At 8:55 AM -0600 12/5/05, Hongwei Li wrote:
I feared that would be the case. I would move anti-virus testing from clients to the mail server - at least for outgoing mail and especially for those roaming users. Let them switch off outbound mail checking by Norton Antivirus and on your Sendmail mail server install clamav-milter to let it check for virus'. Another good idea is to kick and ban such horrible software like OE. There are much better 'free' alternates like Thunderbird.
Alexander
Thanks for all of your help and suggestion! My linux server has clamav installed and it works well. However, some users still prefer their local antivirus agent. Probably, that is the case and what I can do.
They have 3 reasonable choices:
1) Use your recommended method, and be able to send mail.
2) Stick with Norton, and be unable to send mail.
3) Replace Norton with something that isn't dangerous crap.
They should do option 3 even if they chose option 1 above. Norton anything on any platform has always been dangerous crap. If you maintain their systems, you should replace Norton in self-defense. Using /anything/ else will save you work. ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
Am Mo, den 05.12.2005 schrieb Hongwei Li um 15:55:
I feared that would be the case. I would move anti-virus testing from clients to the mail server - at least for outgoing mail and especially for those roaming users. Let them switch off outbound mail checking by Norton Antivirus and on your Sendmail mail server install clamav-milter to let it check for virus'. Another good idea is to kick and ban such horrible software like OE. There are much better 'free' alternates like Thunderbird.
Alexander
Thanks for all of your help and suggestion! My linux server has clamav installed and it works well. However, some users still prefer their local antivirus agent. Probably, that is the case and what I can do.
Hongwei
As said several times before in this thread: users don't have to fully disable or even uninstall Norton Antivirus to be able to send mail using OE over a TLS encrypted connection. Make them just to switch off outbound mail virus testing. Either you make them understand or they just will have a problem.
Alexander
From: "Hongwei Li" hongwei@wustl.edu
probably the best way to handle the "travelling user" need is with smtp-auth -- where the sending client authenticates.
look at/for the following lines in your sendmail.mc
dnl # The following causes sendmail to additionally listen to port 587 for dnl # mail from MUAs that authenticate. Roaming users who can't reach their dnl # preferred sendmail daemon due to port 25 being blocked or redirected find dnl # this useful.
the concept of temporarily adding a random/dynamic ipnumber isn't very good as it open a (admittedly probably small) window that might be able to be used by a spammer type should they come upon it.
Thank you very much for the help! I uncomment the line
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
but, I have a question: if outlook express does not use port 587, then what to do? How to make sure that if outlook express finds port 25 blocked, it will try port 587?
The question is mooted. Outlook Express can set to port 587 or any other port you want. (I experimented with an offbeat port at one time just to check this.)
{^_^}