Re: [qmailtoaster] Development version
I did understand the discussion. I was just making the point that when one does cram-md5 as opposed to plain or login that the password travels across an encrypted tunnel in all instances; however, the difference between 587 and 465 is that 587 does not start as an encrypted session, 465 does. On 1/27/2019 8:35 PM, Andrew Swartz wrote: Eric, I use port 465/TLS for submission, so I agree completely with you. But I think the discussion was regarding using port 587/STARTTLS. In that setting, STARTTLS is vulnerable to a downgrade attack which tricks the conversation to authenticating without the STARTTLS encryption. So if one uses STARTTLS, one must rely on the SMTPAUTH encryption (cram-md5). However, that too is vulnerable (dictionary attack, I believe). This is the reason the RFC now recommends port 465/TLS. At least, that's my understanding. -Andy On 1/27/2019 6:19 PM, Eric Broch wrote: The password encryption is inside an encrypted tunnel. IMHO opinion it's really quite useless. On 1/27/2019 8:16 PM, Andrew Swartz wrote: Ahhh... that's right. But then the next question is should one use cram-md5? I believe it is currently considered insecure. I just found this link which explains the qmail SMTPAUTH options: https://www.fehcom.de/qmail/smtpauth.html##SETUP Unless there is a newer patch, it looks like cram-md5 is the only password encryption option. -Andy On 1/27/2019 11:20 AM, Philip Nix Guru wrote: Hello Andy it is indeed a parameter you set in the env variable in the run file (in my case I set it up in the submission run file) cat /var/qmail/supervise/submission/run #!/bin/sh QMAILDUID=`id -u vpopmail` NOFILESGID=`id -g vpopmail` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` SMTPD="/var/qmail/bin/qmail-smtpd" TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" HOSTNAME=`hostname` VCHKPW="/home/vpopmail/bin/vchkpw" export SMTPAUTH="!+cram" <-- exec /usr/bin/softlimit -m 12800 \ /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 587 \ $SMTPD $VCHKPW /bin/true 2>&1 The current _qmail-authentication_ patch allows you to use the environment variable SMTPAUTH for *qmail-smtpd* in the following way: SMTPAUTH settings for *qmail-smtpd * *SMTPAUTH* *Meaning* "" Left blank to allow Authentication types "PLAIN" and "LOGIN" "+cram" Add "CRAM-MD5" support "cram" Just (secure) "CRAM-MD5" support, no other types offered "!" Enforcing SMTP Auth (of type "LOGIN" or "PLAIN") "!cram" Enforcing SMTP Auth of type "CRAM-MD5" "!+cram" Enforcing SMTP Auth of type "LOGIN", "PLAIN", or "CRAM-MD5" "-" Disabling SMTP Auth (for a particular connection) The complete patch info is listed here : https://www.fehcom.de/qmail/smtpauth.html Regards -P On 1/26/19 8:06 PM, Andrew Swartz wrote: My guess is that there must be a difference in the patches applied to qmail-smtpd or a different compile time option. I don't think this is a simple setting (like in qmail/control). When the connection comes in, tcpserver forwards it to qmail-smtpd. If STARTTLS is invoked, qmail-smtpd hands that task off to openssl, which then returns the decrypted plaintext. But the password processing, whether plain, login, or encrypted, is likely handled directly by qmail-smtpd. Is anyone out there familiar enough with the source code to confirm or refute this? If it is a compile option, it should be fixable with mild to moderate effort. If it is a patch change, that seems more difficult (at least with my skill level). If you figure this out, please let us know, as others will likely be making the migration in the future. -Andy On 1/25/2019 1:21 AM, Philip Nix Guru wrote: I tested with Thunderbird (where the account was working fine with stable version and encrypted password on starttls) and the message came up after the upgrade to change to normal password. When lamba users will get that message they ll just panic and wont know what to do. I still need to check how outlook will react ... On 1/25/19 10:52 AM, Tommi Järvilehto wrote: Was there a problem with Outlook and encrypted passwords? Or the password cache? On 25.1.2019 11:43, Philip Nix Guru wrote: Hello Yes that's one of the reason I was wondering why encrypted password was no longer supported for STARTTLS in the lastest dev version Regards -P On 1/25/19 8:56 AM, Andrew Swartz wrote: I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to s
Re: [qmailtoaster] Development version
Eric, I use port 465/TLS for submission, so I agree completely with you. But I think the discussion was regarding using port 587/STARTTLS. In that setting, STARTTLS is vulnerable to a downgrade attack which tricks the conversation to authenticating without the STARTTLS encryption. So if one uses STARTTLS, one must rely on the SMTPAUTH encryption (cram-md5). However, that too is vulnerable (dictionary attack, I believe). This is the reason the RFC now recommends port 465/TLS. At least, that's my understanding. -Andy On 1/27/2019 6:19 PM, Eric Broch wrote: The password encryption is inside an encrypted tunnel. IMHO opinion it's really quite useless. On 1/27/2019 8:16 PM, Andrew Swartz wrote: Ahhh... that's right. But then the next question is should one use cram-md5? I believe it is currently considered insecure. I just found this link which explains the qmail SMTPAUTH options: https://www.fehcom.de/qmail/smtpauth.html##SETUP Unless there is a newer patch, it looks like cram-md5 is the only password encryption option. -Andy On 1/27/2019 11:20 AM, Philip Nix Guru wrote: Hello Andy it is indeed a parameter you set in the env variable in the run file (in my case I set it up in the submission run file) cat /var/qmail/supervise/submission/run #!/bin/sh QMAILDUID=`id -u vpopmail` NOFILESGID=`id -g vpopmail` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` SMTPD="/var/qmail/bin/qmail-smtpd" TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" HOSTNAME=`hostname` VCHKPW="/home/vpopmail/bin/vchkpw" export SMTPAUTH="!+cram" <-- exec /usr/bin/softlimit -m 12800 \ /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 587 \ $SMTPD $VCHKPW /bin/true 2>&1 The current _qmail-authentication_ patch allows you to use the environment variable SMTPAUTH for *qmail-smtpd* in the following way: SMTPAUTH settings for *qmail-smtpd * *SMTPAUTH* *Meaning* "" Left blank to allow Authentication types "PLAIN" and "LOGIN" "+cram" Add "CRAM-MD5" support "cram" Just (secure) "CRAM-MD5" support, no other types offered "!" Enforcing SMTP Auth (of type "LOGIN" or "PLAIN") "!cram" Enforcing SMTP Auth of type "CRAM-MD5" "!+cram" Enforcing SMTP Auth of type "LOGIN", "PLAIN", or "CRAM-MD5" "-" Disabling SMTP Auth (for a particular connection) The complete patch info is listed here : https://www.fehcom.de/qmail/smtpauth.html Regards -P On 1/26/19 8:06 PM, Andrew Swartz wrote: My guess is that there must be a difference in the patches applied to qmail-smtpd or a different compile time option. I don't think this is a simple setting (like in qmail/control). When the connection comes in, tcpserver forwards it to qmail-smtpd. If STARTTLS is invoked, qmail-smtpd hands that task off to openssl, which then returns the decrypted plaintext. But the password processing, whether plain, login, or encrypted, is likely handled directly by qmail-smtpd. Is anyone out there familiar enough with the source code to confirm or refute this? If it is a compile option, it should be fixable with mild to moderate effort. If it is a patch change, that seems more difficult (at least with my skill level). If you figure this out, please let us know, as others will likely be making the migration in the future. -Andy On 1/25/2019 1:21 AM, Philip Nix Guru wrote: I tested with Thunderbird (where the account was working fine with stable version and encrypted password on starttls) and the message came up after the upgrade to change to normal password. When lamba users will get that message they ll just panic and wont know what to do. I still need to check how outlook will react ... On 1/25/19 10:52 AM, Tommi Järvilehto wrote: Was there a problem with Outlook and encrypted passwords? Or the password cache? On 25.1.2019 11:43, Philip Nix Guru wrote: Hello Yes that's one of the reason I was wondering why encrypted password was no longer supported for STARTTLS in the lastest dev version Regards -P On 1/25/19 8:56 AM, Andrew Swartz wrote: I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to scan people's outgoing email. That means PLAIN or LOGIN type submission passwords can be seen. This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has strongly recommended abandoning STARTTLS on port 587 and using dedicated TLS on port 465 for mail submission. -Andy On 1/24/2019 9:30 PM, Eric Broch wrote: The password is n
Re: [qmailtoaster] Development version
The password encryption is inside an encrypted tunnel. IMHO opinion it's really quite useless. On 1/27/2019 8:16 PM, Andrew Swartz wrote: Ahhh... that's right. But then the next question is should one use cram-md5? I believe it is currently considered insecure. I just found this link which explains the qmail SMTPAUTH options: https://www.fehcom.de/qmail/smtpauth.html##SETUP Unless there is a newer patch, it looks like cram-md5 is the only password encryption option. -Andy On 1/27/2019 11:20 AM, Philip Nix Guru wrote: Hello Andy it is indeed a parameter you set in the env variable in the run file (in my case I set it up in the submission run file) cat /var/qmail/supervise/submission/run #!/bin/sh QMAILDUID=`id -u vpopmail` NOFILESGID=`id -g vpopmail` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` SMTPD="/var/qmail/bin/qmail-smtpd" TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" HOSTNAME=`hostname` VCHKPW="/home/vpopmail/bin/vchkpw" export SMTPAUTH="!+cram" <-- exec /usr/bin/softlimit -m 12800 \ /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 587 \ $SMTPD $VCHKPW /bin/true 2>&1 The current _qmail-authentication_ patch allows you to use the environment variable SMTPAUTH for *qmail-smtpd* in the following way: SMTPAUTH settings for *qmail-smtpd * *SMTPAUTH* *Meaning* "" Left blank to allow Authentication types "PLAIN" and "LOGIN" "+cram" Add "CRAM-MD5" support "cram" Just (secure) "CRAM-MD5" support, no other types offered "!" Enforcing SMTP Auth (of type "LOGIN" or "PLAIN") "!cram" Enforcing SMTP Auth of type "CRAM-MD5" "!+cram" Enforcing SMTP Auth of type "LOGIN", "PLAIN", or "CRAM-MD5" "-" Disabling SMTP Auth (for a particular connection) The complete patch info is listed here : https://www.fehcom.de/qmail/smtpauth.html Regards -P On 1/26/19 8:06 PM, Andrew Swartz wrote: My guess is that there must be a difference in the patches applied to qmail-smtpd or a different compile time option. I don't think this is a simple setting (like in qmail/control). When the connection comes in, tcpserver forwards it to qmail-smtpd. If STARTTLS is invoked, qmail-smtpd hands that task off to openssl, which then returns the decrypted plaintext. But the password processing, whether plain, login, or encrypted, is likely handled directly by qmail-smtpd. Is anyone out there familiar enough with the source code to confirm or refute this? If it is a compile option, it should be fixable with mild to moderate effort. If it is a patch change, that seems more difficult (at least with my skill level). If you figure this out, please let us know, as others will likely be making the migration in the future. -Andy On 1/25/2019 1:21 AM, Philip Nix Guru wrote: I tested with Thunderbird (where the account was working fine with stable version and encrypted password on starttls) and the message came up after the upgrade to change to normal password. When lamba users will get that message they ll just panic and wont know what to do. I still need to check how outlook will react ... On 1/25/19 10:52 AM, Tommi Järvilehto wrote: Was there a problem with Outlook and encrypted passwords? Or the password cache? On 25.1.2019 11:43, Philip Nix Guru wrote: Hello Yes that's one of the reason I was wondering why encrypted password was no longer supported for STARTTLS in the lastest dev version Regards -P On 1/25/19 8:56 AM, Andrew Swartz wrote: I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to scan people's outgoing email. That means PLAIN or LOGIN type submission passwords can be seen. This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has strongly recommended abandoning STARTTLS on port 587 and using dedicated TLS on port 465 for mail submission. -Andy On 1/24/2019 9:30 PM, Eric Broch wrote: The password is not encrypted (Normal) but is sent over an encrypted connection, it's safe. On 1/24/2019 5:39 PM, Philip Nix Guru wrote: Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a
Re: [qmailtoaster] Development version
Ahhh... that's right. But then the next question is should one use cram-md5? I believe it is currently considered insecure. I just found this link which explains the qmail SMTPAUTH options: https://www.fehcom.de/qmail/smtpauth.html##SETUP Unless there is a newer patch, it looks like cram-md5 is the only password encryption option. -Andy On 1/27/2019 11:20 AM, Philip Nix Guru wrote: Hello Andy it is indeed a parameter you set in the env variable in the run file (in my case I set it up in the submission run file) cat /var/qmail/supervise/submission/run #!/bin/sh QMAILDUID=`id -u vpopmail` NOFILESGID=`id -g vpopmail` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` SMTPD="/var/qmail/bin/qmail-smtpd" TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" HOSTNAME=`hostname` VCHKPW="/home/vpopmail/bin/vchkpw" export SMTPAUTH="!+cram" <-- exec /usr/bin/softlimit -m 12800 \ /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 587 \ $SMTPD $VCHKPW /bin/true 2>&1 The current _qmail-authentication_ patch allows you to use the environment variable SMTPAUTH for *qmail-smtpd* in the following way: SMTPAUTH settings for *qmail-smtpd * *SMTPAUTH**Meaning* ""Left blank to allow Authentication types "PLAIN" and "LOGIN" "+cram" Add "CRAM-MD5" support "cram"Just (secure) "CRAM-MD5" support, no other types offered "!" Enforcing SMTP Auth (of type "LOGIN" or "PLAIN") "!cram" Enforcing SMTP Auth of type "CRAM-MD5" "!+cram" Enforcing SMTP Auth of type "LOGIN", "PLAIN", or "CRAM-MD5" "-" Disabling SMTP Auth (for a particular connection) The complete patch info is listed here : https://www.fehcom.de/qmail/smtpauth.html Regards -P On 1/26/19 8:06 PM, Andrew Swartz wrote: My guess is that there must be a difference in the patches applied to qmail-smtpd or a different compile time option. I don't think this is a simple setting (like in qmail/control). When the connection comes in, tcpserver forwards it to qmail-smtpd. If STARTTLS is invoked, qmail-smtpd hands that task off to openssl, which then returns the decrypted plaintext. But the password processing, whether plain, login, or encrypted, is likely handled directly by qmail-smtpd. Is anyone out there familiar enough with the source code to confirm or refute this? If it is a compile option, it should be fixable with mild to moderate effort. If it is a patch change, that seems more difficult (at least with my skill level). If you figure this out, please let us know, as others will likely be making the migration in the future. -Andy On 1/25/2019 1:21 AM, Philip Nix Guru wrote: I tested with Thunderbird (where the account was working fine with stable version and encrypted password on starttls) and the message came up after the upgrade to change to normal password. When lamba users will get that message they ll just panic and wont know what to do. I still need to check how outlook will react ... On 1/25/19 10:52 AM, Tommi Järvilehto wrote: Was there a problem with Outlook and encrypted passwords? Or the password cache? On 25.1.2019 11:43, Philip Nix Guru wrote: Hello Yes that's one of the reason I was wondering why encrypted password was no longer supported for STARTTLS in the lastest dev version Regards -P On 1/25/19 8:56 AM, Andrew Swartz wrote: I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to scan people's outgoing email. That means PLAIN or LOGIN type submission passwords can be seen. This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has strongly recommended abandoning STARTTLS on port 587 and using dedicated TLS on port 465 for mail submission. -Andy On 1/24/2019 9:30 PM, Eric Broch wrote: The password is not encrypted (Normal) but is sent over an encrypted connection, it's safe. On 1/24/2019 5:39 PM, Philip Nix Guru wrote: Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a starttls config in their mail client had to change from encrypted to normal which of course brought the question "oh it is not safe anymore
Re: [qmailtoaster] Development version
Hello Andy it is indeed a parameter you set in the env variable in the run file (in my case I set it up in the submission run file) cat /var/qmail/supervise/submission/run #!/bin/sh QMAILDUID=`id -u vpopmail` NOFILESGID=`id -g vpopmail` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` SMTPD="/var/qmail/bin/qmail-smtpd" TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" HOSTNAME=`hostname` VCHKPW="/home/vpopmail/bin/vchkpw" export SMTPAUTH="!+cram" <-- exec /usr/bin/softlimit -m 12800 \ /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 587 \ $SMTPD $VCHKPW /bin/true 2>&1 The current _qmail-authentication_ patch allows you to use the environment variable SMTPAUTH for *qmail-smtpd* in the following way: SMTPAUTH settings for *qmail-smtpd * *SMTPAUTH**Meaning* ""Left blank to allow Authentication types "PLAIN" and "LOGIN" "+cram" Add "CRAM-MD5" support "cram"Just (secure) "CRAM-MD5" support, no other types offered "!" Enforcing SMTP Auth (of type "LOGIN" or "PLAIN") "!cram" Enforcing SMTP Auth of type "CRAM-MD5" "!+cram" Enforcing SMTP Auth of type "LOGIN", "PLAIN", or "CRAM-MD5" "-" Disabling SMTP Auth (for a particular connection) The complete patch info is listed here : https://www.fehcom.de/qmail/smtpauth.html Regards -P On 1/26/19 8:06 PM, Andrew Swartz wrote: My guess is that there must be a difference in the patches applied to qmail-smtpd or a different compile time option. I don't think this is a simple setting (like in qmail/control). When the connection comes in, tcpserver forwards it to qmail-smtpd. If STARTTLS is invoked, qmail-smtpd hands that task off to openssl, which then returns the decrypted plaintext. But the password processing, whether plain, login, or encrypted, is likely handled directly by qmail-smtpd. Is anyone out there familiar enough with the source code to confirm or refute this? If it is a compile option, it should be fixable with mild to moderate effort. If it is a patch change, that seems more difficult (at least with my skill level). If you figure this out, please let us know, as others will likely be making the migration in the future. -Andy On 1/25/2019 1:21 AM, Philip Nix Guru wrote: I tested with Thunderbird (where the account was working fine with stable version and encrypted password on starttls) and the message came up after the upgrade to change to normal password. When lamba users will get that message they ll just panic and wont know what to do. I still need to check how outlook will react ... On 1/25/19 10:52 AM, Tommi Järvilehto wrote: Was there a problem with Outlook and encrypted passwords? Or the password cache? On 25.1.2019 11:43, Philip Nix Guru wrote: Hello Yes that's one of the reason I was wondering why encrypted password was no longer supported for STARTTLS in the lastest dev version Regards -P On 1/25/19 8:56 AM, Andrew Swartz wrote: I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to scan people's outgoing email. That means PLAIN or LOGIN type submission passwords can be seen. This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has strongly recommended abandoning STARTTLS on port 587 and using dedicated TLS on port 465 for mail submission. -Andy On 1/24/2019 9:30 PM, Eric Broch wrote: The password is not encrypted (Normal) but is sent over an encrypted connection, it's safe. On 1/24/2019 5:39 PM, Philip Nix Guru wrote: Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a starttls config in their mail client had to change from encrypted to normal which of course brought the question "oh it is not safe anymore ..." Regards -Philip - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For a
Re: [qmailtoaster] Development version
I tested with Thunderbird (where the account was working fine with stable version and encrypted password on starttls) and the message came up after the upgrade to change to normal password. When lamba users will get that message they ll just panic and wont know what to do. I still need to check how outlook will react ... On 1/25/19 10:52 AM, Tommi Järvilehto wrote: Was there a problem with Outlook and encrypted passwords? Or the password cache? On 25.1.2019 11:43, Philip Nix Guru wrote: Hello Yes that's one of the reason I was wondering why encrypted password was no longer supported for STARTTLS in the lastest dev version Regards -P On 1/25/19 8:56 AM, Andrew Swartz wrote: I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to scan people's outgoing email. That means PLAIN or LOGIN type submission passwords can be seen. This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has strongly recommended abandoning STARTTLS on port 587 and using dedicated TLS on port 465 for mail submission. -Andy On 1/24/2019 9:30 PM, Eric Broch wrote: The password is not encrypted (Normal) but is sent over an encrypted connection, it's safe. On 1/24/2019 5:39 PM, Philip Nix Guru wrote: Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a starttls config in their mail client had to change from encrypted to normal which of course brought the question "oh it is not safe anymore ..." Regards -Philip - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Development version
Was there a problem with Outlook and encrypted passwords? Or the password cache? On 25.1.2019 11:43, Philip Nix Guru wrote: Hello Yes that's one of the reason I was wondering why encrypted password was no longer supported for STARTTLS in the lastest dev version Regards -P On 1/25/19 8:56 AM, Andrew Swartz wrote: I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to scan people's outgoing email. That means PLAIN or LOGIN type submission passwords can be seen. This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has strongly recommended abandoning STARTTLS on port 587 and using dedicated TLS on port 465 for mail submission. -Andy On 1/24/2019 9:30 PM, Eric Broch wrote: The password is not encrypted (Normal) but is sent over an encrypted connection, it's safe. On 1/24/2019 5:39 PM, Philip Nix Guru wrote: Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a starttls config in their mail client had to change from encrypted to normal which of course brought the question "oh it is not safe anymore ..." Regards -Philip - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- Tommi Järvilehto DataVahti Oy 040 732 8032 - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Development version
Hello Yes that's one of the reason I was wondering why encrypted password was no longer supported for STARTTLS in the lastest dev version Regards -P On 1/25/19 8:56 AM, Andrew Swartz wrote: I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to scan people's outgoing email. That means PLAIN or LOGIN type submission passwords can be seen. This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has strongly recommended abandoning STARTTLS on port 587 and using dedicated TLS on port 465 for mail submission. -Andy On 1/24/2019 9:30 PM, Eric Broch wrote: The password is not encrypted (Normal) but is sent over an encrypted connection, it's safe. On 1/24/2019 5:39 PM, Philip Nix Guru wrote: Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a starttls config in their mail client had to change from encrypted to normal which of course brought the question "oh it is not safe anymore ..." Regards -Philip - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Development version
I would add the caveat that STARTTLS is only "probably safe". Unfortunately, it suffers from a critical error in the very concept of going from an plaintext session to a TLS session, resulting in an unfixable (as far as I know) vulnerability. A man-in-the-middle can inject text into the server response to tell the client that STARTTLS is not available and that the conversation should therefore continue in plaintext. I've read that several ISP's have been caught using this vulnerability to scan people's outgoing email. That means PLAIN or LOGIN type submission passwords can be seen. This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has strongly recommended abandoning STARTTLS on port 587 and using dedicated TLS on port 465 for mail submission. -Andy On 1/24/2019 9:30 PM, Eric Broch wrote: The password is not encrypted (Normal) but is sent over an encrypted connection, it's safe. On 1/24/2019 5:39 PM, Philip Nix Guru wrote: Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a starttls config in their mail client had to change from encrypted to normal which of course brought the question "oh it is not safe anymore ..." Regards -Philip - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Development version
The password is not encrypted (Normal) but is sent over an encrypted connection, it's safe. On 1/24/2019 5:39 PM, Philip Nix Guru wrote: Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a starttls config in their mail client had to change from encrypted to normal which of course brought the question "oh it is not safe anymore ..." Regards -Philip - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- Eric Broch White Horse Technical Consulting (WHTC) - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Development version
Hello I was testing the dev version (an upgrade over the stable version) and came through that annoying problem if I have to advise all users to change their config : Sending of the message failed. The Outgoing server (SMTP) xx does not seem to support encrypted passwords. If you just set up the account, try changing the 'Authentication method' in 'Account settings | Outgoing server (SMTP)' to 'Normal password'. All the users having a starttls config in their mail client had to change from encrypted to normal which of course brought the question "oh it is not safe anymore ..." Regards -Philip - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
