Hi Everyone! I've setup dovecot 2.3.2.1 on a Gentoo server. I want to configure the submission service in order to replace the corresponding part in Postfix (which is my SMTP server). I configured submission it with just a few options different of the default ones: submission_client_workarounds = whitespace-before-path submission_relay_host = 127.0.0.1 submission_relay_port = 10026 submission_relay_trusted = yes The issue I'm having is that the SMTP AUTH is enforced and performed correctly, but it doesn't get published on the server capaabilities when the connection doesn't come from localhost. This causes issues with some smtp clients which authenticate (python smtpclient). When I telnet the submission service from localhost I get: 220 (protected hostname) Dovecot ready. EHLO L 250-(protected hostname) 250-8BITMIME 250-AUTH PLAIN LOGIN 250-BURL imap 250-CHUNKING 250-ENHANCEDSTATUSCODES 250-SIZE 250-STARTTLS 250 PIPELINING quit 221 2.0.0 Bye But when I do the same from another host other than the one running dovecot (telnetting the submission port): 220 (protected hostname) Dovecot ready. EHLO L 250-(protected hostname) 250-8BITMIME 250-BURL imap 250-CHUNKING 250-ENHANCEDSTATUSCODES 250-SIZE 250-STARTTLS 250 PIPELINING quit 221 2.0.0 Bye As you can see, the AUTH capability is not there. Do you know what could be causing this issue? Your help is much appreciated! German
On June 21, 2019 3:13:59 PM GMT+02:00, "Germ?n Herrera via dovecot" <dovecot at dovecot.org> wrote:>Hi Everyone! > >I've setup dovecot 2.3.2.1 on a Gentoo server. I want to configure the >submission service in order to replace the corresponding part in >Postfix >(which is my SMTP server). >I configured submission it with just a few options different of the >default ones: > >submission_client_workarounds = whitespace-before-path >submission_relay_host = 127.0.0.1 >submission_relay_port = 10026 >submission_relay_trusted = yes > >The issue I'm having is that the SMTP AUTH is enforced and performed >correctly, but it doesn't get published on the server capaabilities >when >the connection doesn't come from localhost. This causes issues with >some >smtp clients which authenticate (python smtpclient). > >When I telnet the submission service from localhost I get: > >220 (protected hostname) Dovecot ready. >EHLO L >250-(protected hostname) >250-8BITMIME >250-AUTH PLAIN LOGIN >250-BURL imap >250-CHUNKING >250-ENHANCEDSTATUSCODES >250-SIZE >250-STARTTLS >250 PIPELINING >quit >221 2.0.0 Bye > >But when I do the same from another host other than the one running >dovecot (telnetting the submission port): > >220 (protected hostname) Dovecot ready. >EHLO L >250-(protected hostname) >250-8BITMIME >250-BURL imap >250-CHUNKING >250-ENHANCEDSTATUSCODES >250-SIZE >250-STARTTLS >250 PIPELINING >quit >221 2.0.0 Bye > >As you can see, the AUTH capability is not there. >Do you know what could be causing this issue? Your help is much >appreciated! >GermanMaybe you need to start tls before auth will be offered as localhost most often is whitelisted from the need for auth. Have you tried with openssl s_client to start TLS and see if auth is offered then? -- Christian Kivalo
Hi Christian, first of all I appreciate your quick answer. You are correct, if I "openssl -starttls smtp -connect <host>:<port>" I notice the AUTH capability is published, so that explains why the clients that I configure with STARTTLS are able to find out the AUTH mechanisms and authenticate correctly. I also found out that the AUTH is shown before entering STARTTLS if I set "ssl = yes", but the capability is hidden from pre-starttls EHLO if I do enforce SSL with "ssl = required", which is my server configuration. That is an strange behavior for me, but I can deal with it now that I know how it works. Thanks for your help, and best regards!! German On 2019-06-21 11:05, Christian Kivalo via dovecot wrote:> On June 21, 2019 3:13:59 PM GMT+02:00, "Germ?n Herrera via dovecot" > <dovecot at dovecot.org> wrote: >> Hi Everyone! >> >> I've setup dovecot 2.3.2.1 on a Gentoo server. I want to configure the >> submission service in order to replace the corresponding part in >> Postfix >> (which is my SMTP server). >> I configured submission it with just a few options different of the >> default ones: >> >> submission_client_workarounds = whitespace-before-path >> submission_relay_host = 127.0.0.1 >> submission_relay_port = 10026 >> submission_relay_trusted = yes >> >> The issue I'm having is that the SMTP AUTH is enforced and performed >> correctly, but it doesn't get published on the server capaabilities >> when >> the connection doesn't come from localhost. This causes issues with >> some >> smtp clients which authenticate (python smtpclient). >> >> When I telnet the submission service from localhost I get: >> >> 220 (protected hostname) Dovecot ready. >> EHLO L >> 250-(protected hostname) >> 250-8BITMIME >> 250-AUTH PLAIN LOGIN >> 250-BURL imap >> 250-CHUNKING >> 250-ENHANCEDSTATUSCODES >> 250-SIZE >> 250-STARTTLS >> 250 PIPELINING >> quit >> 221 2.0.0 Bye >> >> But when I do the same from another host other than the one running >> dovecot (telnetting the submission port): >> >> 220 (protected hostname) Dovecot ready. >> EHLO L >> 250-(protected hostname) >> 250-8BITMIME >> 250-BURL imap >> 250-CHUNKING >> 250-ENHANCEDSTATUSCODES >> 250-SIZE >> 250-STARTTLS >> 250 PIPELINING >> quit >> 221 2.0.0 Bye >> >> As you can see, the AUTH capability is not there. >> Do you know what could be causing this issue? Your help is much >> appreciated! >> German > Maybe you need to start tls before auth will be offered as localhost > most often is whitelisted from the need for auth. Have you tried with > openssl s_client to start TLS and see if auth is offered then?
Apparently Analagous Threads
- submission configuration issues
- submission configuration issues
- Submission service and SMTP AUTH capability
- Submission service and SMTP AUTH capability
- dovecot warns (non-fatal) "invalid EHLO response line: Unexpected character in EHLO keyword" connecting to submission relay ?