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
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
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
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`
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
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
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
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
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
