SMTP Authentication without Encryption

[Stephan Brauss]

Hi!

The SMTP server of my ISP requires authentification (user/password), but 
I do not want to use SASL and SSL/TLS.
Is it possible to have a plain text/unencrypted connection but still use 
authentification? - I tried with various settings in main.cf but without 
success. I do not manage to get authentification without encryption.


Thanks & best regards,
Stephan

Re: SMTP Authentication without Encryption

[Stephan Brauss]

Hi!

Yes, the ISP supports auth without SSL/TLS, but how can I configure 
postfix to use it? - I mean in all settings I can find, auth is always 
linked to SASL SSL/TLS.


Cheers
Stephan


Am 12.07.2017 um 15:53 schrieb Gilberto Nunes:

Hi

AFAIK your isp must support auth methods other than SSL/TLS

Cheers


Obrigado

Cordialmente


Gilberto Ferreira


Consultor TI Linux | IaaS Proxmox, CloudStack, KVM | Zentyal Server
| Zimbra Mail Server

*
*
(47) 3025-5907
**
(47) 99676-7530

Skype: gilberto.nunes36


konnectati.com.br 


https://www.youtube.com/watch?v=dsiTPeNWcSE



2017-07-12 10:48 GMT-03:00 Stephan Brauss >:


Hi!

The SMTP server of my ISP requires authentification (user/password),
but I do not want to use SASL and SSL/TLS.
Is it possible to have a plain text/unencrypted connection but still
use authentification? - I tried with various settings in main.cf
 but without success. I do not manage to get
authentification without encryption.

Thanks & best regards,
Stephan

Postfix 3.2.0 - Sending to all MX records

[Tom Hudson]

Firstly, apologies if I haven't included all of the relevant information in
this initial post. Please let me know if I have missed anything.

I am currently running Postfix 3.2.0 and have a problem relating to MX
records and defered messages. What I have identified is, if a domain our
server is trying to send to has an MX record which returns no response, the
message is defered. Every time postfix attempts to redeliver this message,
it uses the same lowest priority MX record.

I have found examples in our mail queue which are deferred with the reason
"unknown mail transport error". When I attempt to telnet to the MX records
for their domain, their lowest value MX is not contactable but the others
are.

We can see no traffic attempting to go from postfix to the other MX records,
only the lowest value every time.

I understand that it should be standard practice for Postfix to first
attempt the lowest value and then attempt to use all other MX records before
deferring the message.

Can anyone advise why this isn't working for me? I'll include any postconf
settings which I think are relevant below and please tell me if you need any
more information;

ignore_mx_lookup_error = no
smtp_defer_if_no_mx_address_found = no
smtp_mx_address_limit = 20
smtp_mx_session_limit = 5
smtp_skip_5xx_greeting = yes
smtp_skip_quit_response = yes



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postfix-3-2-0-Sending-to-all-MX-records-tp91255.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: SMTP Authentication without Encryption

[Stephan Brauss]

Hi!

> Can you send us what conf do you use? Part of your main.cf
These are the parameters I played with:
relayhost = [smtp.hispeed.ch]:587
#relayhost = [smtp.hispeed.ch]:25
smtp_sasl_auth_enable = no
smtp_use_tls = no
#smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
#smtp_tls_CAfile = /etc/mail/certs/cacert.pem
smtp_sasl_tls_security_options = noanonymous

The only place I found where I can place user/password is in the file 
refered to by smtp_sasl_password_maps. But this is SASL related, or am I 
wrong?


> …why?  This seems like an incredibly bad idea.
sure... where from have you your certificate?

Thanks!
Stephan

Re: SMTP Authentication without Encryption

[Gilberto Nunes]

Here I am using Google ( smtp.gmail.com )

relayhost = smtp.gmail.com


smtp_tls_security_level = may
smtp_tls_key_file  = /etc/postfix/sasl/postfix.pem
smtp_tls_cert_file = /etc/postfix/sasl/postfix.pem

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

In sasl_passwd I set this:

smtp.gmail.com myuser:mypassword

Do not forget to make postmap in sasl_passwd, in order to generate the
sasl_passwd.db, since postfix do no read sasl_passwd itself, as you may
know...






Obrigado

Cordialmente


Gilberto Ferreira

Consultor TI Linux | IaaS Proxmox, CloudStack, KVM | Zentyal Server |
Zimbra Mail Server

(47) 3025-5907
(47) 99676-7530

Skype: gilberto.nunes36


konnectati.com.br 


https://www.youtube.com/watch?v=dsiTPeNWcSE


2017-07-12 11:18 GMT-03:00 Stephan Brauss :

> Hi!
>
> > Can you send us what conf do you use? Part of your main.cf
> These are the parameters I played with:
> relayhost = [smtp.hispeed.ch]:587
> #relayhost = [smtp.hispeed.ch]:25
> smtp_sasl_auth_enable = no
> smtp_use_tls = no
> #smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> #smtp_tls_CAfile = /etc/mail/certs/cacert.pem
> smtp_sasl_tls_security_options = noanonymous
>
> The only place I found where I can place user/password is in the file
> refered to by smtp_sasl_password_maps. But this is SASL related, or am I
> wrong?
>
> > …why?  This seems like an incredibly bad idea.
> sure... where from have you your certificate?
>
> Thanks!
> Stephan
>
>

Re: SMTP Authentication without Encryption

[Viktor Dukhovni]

> On Jul 12, 2017, at 9:48 AM, Stephan Brauss  wrote:
> 
> The SMTP server of my ISP requires authentification (user/password), but
> I do not want to use SASL and SSL/TLS.

The *protocol* used to exchange authentication credentials between SMTP
clients and SMTP servers is the SASL protocol.  Postfix uses SASL libraries
to implement the SASL protocol.

SASL can be used without TLS, but by default, the PLAIN mechanism is
restricted to TLS.  Because storing cleartext passwords on servers is
a security (and reputation for incompetence) risk, most servers only
support PLAIN, and do not support CRAM-MD5 and the like, which require
stored cleartext passwords.

You can enable PLAIN without TLS via the corresponding (non-tls) SASL
options setting, but the ISP may not support PLAIN without TLS, or if
it does so now, may improve their password security in the future and
disallow PLAIN without TLS.

Basically, you're fighting against the tools that properly do the job.
To authenticate with a username and password against a submission
service you need to use SASL and TLS.

-- 
Viktor.

Re: SMTP Authentication without Encryption

[Gilberto Nunes]

Wow! You hit the point!


Obrigado

Cordialmente


Gilberto Ferreira

Consultor TI Linux | IaaS Proxmox, CloudStack, KVM | Zentyal Server |
Zimbra Mail Server

(47) 3025-5907
(47) 99676-7530

Skype: gilberto.nunes36


konnectati.com.br 


https://www.youtube.com/watch?v=dsiTPeNWcSE


2017-07-12 11:44 GMT-03:00 Viktor Dukhovni :

>
> > On Jul 12, 2017, at 9:48 AM, Stephan Brauss  wrote:
> >
> > The SMTP server of my ISP requires authentification (user/password), but
> > I do not want to use SASL and SSL/TLS.
>
> The *protocol* used to exchange authentication credentials between SMTP
> clients and SMTP servers is the SASL protocol.  Postfix uses SASL libraries
> to implement the SASL protocol.
>
> SASL can be used without TLS, but by default, the PLAIN mechanism is
> restricted to TLS.  Because storing cleartext passwords on servers is
> a security (and reputation for incompetence) risk, most servers only
> support PLAIN, and do not support CRAM-MD5 and the like, which require
> stored cleartext passwords.
>
> You can enable PLAIN without TLS via the corresponding (non-tls) SASL
> options setting, but the ISP may not support PLAIN without TLS, or if
> it does so now, may improve their password security in the future and
> disallow PLAIN without TLS.
>
> Basically, you're fighting against the tools that properly do the job.
> To authenticate with a username and password against a submission
> service you need to use SASL and TLS.
>
> --
> Viktor.
>
>

Re: Postfix 3.2.0 - Sending to all MX records

[Viktor Dukhovni]

> On Jul 12, 2017, at 10:08 AM, Tom Hudson  wrote:
> 
> Firstly, apologies if I haven't included all of the relevant information in
> this initial post. Please let me know if I have missed anything.
> 
> I am currently running Postfix 3.2.0 and have a problem relating to MX
> records and defered messages. What I have identified is, if a domain our
> server is trying to send to has an MX record which returns no response, the
> message is defered. Every time postfix attempts to redeliver this message,
> it uses the same lowest priority MX record.

That is not how Postfix generally works.  No further information is possible
without the relevant logs, and any relevant transport table and master.cf
settings.

> I have found examples in our mail queue which are deferred with the reason
> "unknown mail transport error". When I attempt to telnet to the MX records
> for their domain, their lowest value MX is not contactable but the others
> are.

"unknown mail transport error" is a serious problem, which indicates a
delivery agent crash or similar failure to report delivery status to the
queue manager.  You will find the cause in your logs:

http://www.postfix.org/DEBUG_README.html#logging

-- 
Viktor.

Re: Postfix 3.2.0 - Sending to all MX records

[/dev/rob0]

On Wed, Jul 12, 2017 at 07:08:34AM -0700, Tom Hudson wrote:
> Firstly, apologies if I haven't included all of the relevant 
> information in this initial post. Please let me know if I have 
> missed anything.

Full "postconf -nf ; postconf -Mf" and complete non-verbose logging 
of a single email which demonstrates your issue.

> I am currently running Postfix 3.2.0 and have a problem relating to 
> MX records and defered messages. What I have identified is, if a 
> domain our server is trying to send to has an MX record which 
> returns no response, the message is defered. Every time postfix 
> attempts to redeliver this message, it uses the same lowest 
> priority MX record.
> 
> I have found examples in our mail queue which are deferred with the 
> reason "unknown mail transport error". When I attempt to telnet to 

You have changed a transport(5)-related setting to something which 
isn't a valid transport in your master.cf.

> the MX records for their domain, their lowest value MX is not 
> contactable but the others are.
> 
> We can see no traffic attempting to go from postfix to the other MX 
> records, only the lowest value every time.
> 
> I understand that it should be standard practice for Postfix to 
> first attempt the lowest value and then attempt to use all other MX 
> records before deferring the message.
> 
> Can anyone advise why this isn't working for me? I'll include any 
> postconf settings which I think are relevant below and please tell 
> me if you need any more information;
> 
> ignore_mx_lookup_error = no
> smtp_defer_if_no_mx_address_found = no
> smtp_mx_address_limit = 20
> smtp_mx_session_limit = 5
> smtp_skip_5xx_greeting = yes
> smtp_skip_quit_response = yes

See above.  This is not useful.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: upgrade/compile options

[techlist06]

Thanks Peter, appreciate the nudge.  What the hell, I'm in .  I'll try
it on my test server.  It would be nice for me to stay in the yum update
world.




--
View this message in context: 
http://postfix.1071664.n5.nabble.com/upgrade-compile-options-tp91241p91262.html
Sent from the Postfix Users mailing list archive at Nabble.com.

UnTrusted CN presented

[Mal]

Wondering if anyone knows if it's possible to log the certificate CN presented 
when Postfix logs "Untrusted TLS connection established from.." 

Postifx logs the 'UnTrusted' event well, but I'd like to know if you can see 
the CN of the certificate presented by the other party..

Regards,
Mal




Mal.asc
Description: Mal.asc

Re: UnTrusted CN presented

[Viktor Dukhovni]

> On Jul 12, 2017, at 10:46 PM, Mal  wrote:
> 
> Wondering if anyone knows if it's possible to log the certificate CN 
> presented when Postfix logs "Untrusted TLS connection established from.." 

That is not currently possible.  Unconditional logging of the peer certificate
metadata is possible, but the interface is not documented, because a more 
flexible
logging interface is needed in the long term, and just cluttering the current 
logging
interface with more features that have to be supported long-term is not a good 
idea,
if we want to overhaul how logging works in the future.

I am somewhat surprised you say "...established from..." since that would the 
SMTP
server, and the connection would be from an SMTP client, and these very rarely 
have
TLS certificates to present (and most servers do not request client 
certificates).

-- 
Viktor.