COrreaction: smtp should br smtpd. Corrected text follows.
John:
> I have submission sasl set as Venema suggests, should/would it a good
> idea to add "smtpd_sasl_auth_enable=no" to the smtp entry in master.cf,
> or is the default "good enough".
If you're concerned that SASL will be enabled by
John:
> I have submission sasl set as Venema suggests, should/would it a good
> idea to add "smtp_sasl_auth_enable=no" to the smtp entry in master.cf,
> or is the default "good enough".
If you're concerned that SASL will be enabled by accident, you could
set "smtp_sasl_auth_enable=no" in main.cf
I have submission sasl set as Venema suggests, should/would it a good
idea to add "smtp_sasl_auth_enable=no" to the smtp entry in master.cf,
or is the default "good enough".
On 03/12/16 10:10 AM, Wietse Venema wrote:
rich.gre...@hushmail.com:
There are ports that exist for encrypted transfe
rich.gre...@hushmail.com:
> $ telnet example.com 25
> Trying 87.138.xxx.yyy...
> Connected to example.com.
> Escape character is '^]'.
> 220 example.com ESMTP Postfix (Ubuntu)
> ehlo example.com
> 250-example.com
> 250-PIPELINING
> 250-SIZE 1024
> 250-VRFY
> 250-ETRN
> 250-STARTTLS
> 250-AUTH P
rich.gre...@hushmail.com:
> I suspected that was a typo. I figured it out.
>
> I made those changes, when I attempt an AUTH LOGIN, I get back "535 5.7.8
> Error: authentication failed: UGFzc3dvcmQ6" which seems to be appropriate.
You still have AUTH enabled on port 25.
Wietse
On 12/3/2016 at 10:45 AM, "John Fawcett" wrote:
>
>On 12/03/2016 05:25 PM, rich.gre...@hushmail.com wrote:
>> Here I am, replying to my own post again. What I said in the
>prior post wasn't entirely true. I realized that I used the wrong
>password in my prior attempt. I am still granted acc
El 03/12/16 a las 17:25, rich.gre...@hushmail.com escribió:
> So I'm somewhat confused how to prevent/discourage users from sending
> their authentication detail in the clear when there are secure methods
> that exist (such as, $ openssl s_client -starttls smtp -connect
> example.com:587)
We woul
correcting my own typo now
On 12/03/2016 05:44 PM, John Fawcett wrote:
> On 12/03/2016 05:25 PM, rich.gre...@hushmail.com wrote:
>> Here I am, replying to my own post again. What I said in the prior post
>> wasn't entirely true. I realized that I used the wrong password in my prior
>> attempt.
On 12/03/2016 05:25 PM, rich.gre...@hushmail.com wrote:
> Here I am, replying to my own post again. What I said in the prior post
> wasn't entirely true. I realized that I used the wrong password in my prior
> attempt. I am still granted access to the SMTP service after authenticating
> in pl
Here I am, replying to my own post again. What I said in the prior post wasn't
entirely true. I realized that I used the wrong password in my prior attempt.
I am still granted access to the SMTP service after authenticating in plaintext
on port 25.
So I'm somewhat confused how to prevent/dis
I suspected that was a typo. I figured it out.
I made those changes, when I attempt an AUTH LOGIN, I get back "535 5.7.8
Error: authentication failed: UGFzc3dvcmQ6" which seems to be appropriate.
So the user is no longer rewarded with access to the SMTP services when they
attempt to connect u
John Fawcett:
> On 12/03/2016 04:10 PM, Wietse Venema wrote:
> > rich.gre...@hushmail.com:
> >> There are ports that exist for encrypted transfer of this data
> >> (such as 465, 587). What is the current state of the art for
> >> preventing the user's client software from being able to do this
> >
On 12/03/2016 04:10 PM, Wietse Venema wrote:
> rich.gre...@hushmail.com:
>> There are ports that exist for encrypted transfer of this data
>> (such as 465, 587). What is the current state of the art for
>> preventing the user's client software from being able to do this
>> (sending their authentic
rich.gre...@hushmail.com:
> There are ports that exist for encrypted transfer of this data
> (such as 465, 587). What is the current state of the art for
> preventing the user's client software from being able to do this
> (sending their authentication details plaintext)? Is it safe to
> simply b
I love to go and see what I can get away with using telnet. I decided to send
and check email from the command line.
Since I consider my test location to be low risk, I decided to try to send my
password plaintext over port 25. I was a moderately surprised that it did
work, as seen below in t
15 matches
Mail list logo
