Re: Extended logging / moved mails jumping back

[Sami Ketola via dovecot]

> On 19 Apr 2019, at 20.04, Martin Müller via dovecot  
> wrote:
> 
> 2019-04-19 18:53:54 imap-login: Info: Login: user= >, method=PLAIN, rip=80.75.xx.35, 
> lip=136.xxx.9.172, mpid=28364, TLS, session=
> 
> All 4 different MUAs Thunderbird are logged in the same way. They are behind 
> a router, so they having the same remote IP. 
> So I cant differentiate, which MUA causes which event.
> 
> Is there a way, to identify which client raise a special event?

I think Thunderbird does send IMAP ID information so you can try adding 
"imap_id_log = *" to your config to get the info logged.

Maybe it has some information to identify the different clients.

Sami

haproxy + submission services -> postfix failure

[Chris Thomas via dovecot]

Hi,

I have a nginx server which is using the proxy protocol to forward tcp
connections to dovecot. Dovecot is configured to be a submission
service for email to be sent. Then postfix should send the email
itself which is also using the ha proxy protocol. There are a few
moving parts in this problem so I'm not sure where the problem is. But
I want to ask if somebody can validate my dovecot configuration
somehow so I can start to tick off some things from the list.

Sending email fails, seems to get to postfix, then die
Receiving emails succeeds and I don't have any problem to pick them up.

I've figured out some stuff, like lmtp shouldn't use haproxy when
talking between postfix -> dovecot for receiving emails. If I enable
the protocol on lmtp, I can't receive any emails at all.

In order to get postfix to accept emails, I enabled haproxy protocol
and enabled postscreen and then postfix could access the source ip and
stop my server from being an open relay.

I've got tls certificates installed on dovecot and postfix, all
created by letsencrypt and I don't appear to have any problems with
them.

I will try to give as much information about the config as I can, I'm
not sure what other parts are good to have, but let me know if you are
missing something or want to check a value.

>> 10-master.conf:
service submission-login {
  inet_listener submission {
port = 587
haproxy = yes
  }
}

service lmtp {
  inet_listener lmtp {
port = 24
haproxy = no
  }
}


>> 20-submission.conf
submission_relay_host = postfix.mail-server
submission_relay_port = 25
submission_relay_ssl = starttls
submission_relay_ssl_verify = yes

Then because it might help to give the other side of the connection
configuration for postfix, here is the relevant information:

>> master.cf:
smtp  inet  n   -   -   -   1   postscreen
smtpd pass  -   -   -   -   -   smtpd

>> main.cf

postscreen_upstream_proxy_protocol = haproxy
postscreen_upstream_proxy_timeout = 10s

That's it. I don't know what other information could be useful.

There are some logs, they are like this (I've got logging turned on
for pretty much every option I have:

Dovecot logs:

Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
Added userdb setting: plugin/quota_rule=*:bytes=0
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
Effective uid=8, gid=8, home=/mail/__DOMAIN_COM__/__USER__
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no,
list=yes, subscriptions=yes
location=maildir:/mail/__DOMAIN_COM__/__USER__
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
maildir++: root=/mail/__DOMAIN_COM__/__USER__, index=, indexpvt=,
control=, inbox=/mail/__DOMAIN_COM__/__USER__, alt=
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
smtp-server: conn __IP_ADDR_1__:31217 [0]: Connection created
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
smtp-client: conn postfix.mail-server:25 [0]: Connection created
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
smtp-client: conn postfix.mail-server:25 [0]: Looking up IP address
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
smtp-client: conn postfix.mail-server:25 [0]: DNS lookup successful;
got 1 IPs
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
smtp-client: conn postfix.mail-server:25 [0]: Connecting to
10.104.211.161:25
Apr 19 17:54:47 submission(__EMAIL__)<497>: Debug:
smtp-client: conn postfix.mail-server:25 [0]: Connected
Apr 19 17:54:57 submission(__EMAIL__)<497>: Debug:
smtp-client: conn postfix.mail-server:25 [0]: Received greeting from
server: 421 4.3.2 No system resources
Apr 19 17:54:57 submission(__EMAIL__)<497>: Debug:
smtp-client: conn postfix.mail-server:25 [0]: Connection failed: 421
4.3.2 No system resources
Apr 19 17:54:57 submission(__EMAIL__)<497>: Error:
Failed to establish relay connection: 421 4.3.2 No system resources
Apr 19 17:54:57 submission(__EMAIL__)<497>: Debug:
smtp-client: conn postfix.mail-server:25 [0]: Disconnected
Apr 19 17:54:57 submission(__EMAIL__)<497>: Info:
Disconnect from __IP_ADDR_1__: Failed to establish relay connection
in=0 out=22 (state=GREETING)
Apr 19 17:54:57 submission(__EMAIL__)<497>: Debug:
smtp-server: conn __IP_ADDR_1__:31217 [0]: Disconnected: Failed to
establish relay connection

Postfix Logs:
postfix/postscreen[525]: warning: haproxy read: time limit exceeded

If anybody could help out, I'd be grateful because I just can't see
what the problem is.

Chris

Re: Extended logging / moved mails jumping back

[Martin Müller via dovecot]

did some improvements on the server.

from

dovecot -n
# 2.2.13: /etc/dovecot/dovecot.conf
# OS: Linux 3.16.0-6-amd64 x86_64 Debian 8.11

to

# 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.16 (fed8554)
# OS: Linux 4.9.0-8-amd64 x86_64 Debian 9.8

dovecot is working for days without issues, logging is running to one file
/var/log/mail.dovecot

In the logfile appears
2019-04-19 18:53:54 imap-login: Info: Login: user=,
method=PLAIN, rip=80.75.xx.35, lip=136.xxx.9.172, mpid=28364, TLS,
session=

All 4 different MUAs Thunderbird are logged in the same way. They are
behind a router, so they having the same remote IP.
So I cant differentiate, which MUA causes which event.

Is there a way, to identify which client raise a special event?






Am So., 14. Apr. 2019 um 12:38 Uhr schrieb Reto Brunner via dovecot <
dovecot@dovecot.org>:

> On Sun, Apr 14, 2019 at 12:04:36PM +0200, Martin Müller via dovecot wrote:
> > relay=dovecot, delay=0.13, delays=0.07/0/0/0.06, dsn=4.3.0,
> status=deferred
> > (temporary failure. Command output: Can't open log file
> > /var/log/mail.dovecot-error: Permission denied )
> >[...]
> > Here the output of ls -la /var/log/mail.dovecot-error
> > -rw-r--r-- 1 root root   21259 Apr 14 11:24 /var/log/mail.dovecot-error
> >[...]
> > Any hints for me?
>
> Well, fix the permission errors?
> Give write access to the docecot user (or whatever you use) for the log
> file.
>
> Also take care if you use the systemd service, there may be other
> restrictions in place (ProtectSystem etc)
>


-- 
Martin

Re: [Dovecot] Dovecot LDA/LMTP vs postfix virtual delivery agent and the x-original-to header

[Tom Sommer via dovecot]

On 2019-04-19 15:26, Aki Tuomi via dovecot wrote:

Unfortunately we have quite long list of things to do, so sometimes 
even trivial things can take a long time.


Not to hijack the thread, but perhaps you could elaborate on what has 
changed within Dovecot?


Timo seems to be put in the background, releases are less frequent and 
with less changes/additions. The days of "Oh, great idea - I added that, 
see this commit" seem gone.


Is this because OX acquired Dovecot, so priorities have changed? Or what 
is going on?


Mostly just curious.

--
Tom

Re: [Dovecot] Dovecot LDA/LMTP vs postfix virtual delivery agent and the x-original-to header

[Aki Tuomi via dovecot]

 
 
  
   Unfortunately we have quite long list of things to do, so sometimes even trivial things can take a long time.
  
  
   
  
  
   Aki
  
  
   
On 18 April 2019 16:53 Tanstaafl via dovecot <
dovecot@dovecot.org> wrote:
   
   

   
   

   
   
Sadly, I guess not...
   
   

   
   
I'm not sure what to make of this, seeing as both Wietse and Timo said
   
   
it was almost a trivial thing to fix.
   
   

   
   
On Fri Apr 12 2019 12:17:22 GMT-0400 (Eastern Standard Time), Tanstaafl
   
   
via dovecot <
dovecot@dovecot.org> wrote:
   
   

 I'm resurrecting this again because I'm getting pretty close to possibly


 being ready to install a brand new dovecot server (finally), but I still


 need for dovecots LMTP to add the x-original-to header.


 


 So... was this completed quietly, or is support for it still not there?


 


 Thanks,


 


 Charles

   
  
  
   
  
  
   ---
Aki Tuomi
   
 

Re: OAuth Passdb Grant

[Aki Tuomi via dovecot]

> On 19 April 2019 11:11 Tom via dovecot  wrote:
> 
> 
> I'm trying to implement the password grant flow, as specified at 
> https://wiki2.dovecot.org/PasswordDatabase/oauth2,
> but am getting an error message. Can you please help?
> 
> auth: Fatal: oauth2 /etc/dovecot/dovecot-oauth2.token.conf.ext: Error in 
> configuration file /etc/dovecot/dovecot-oauth2.token.conf.ext line 1: Unknown 
> setting: grant_url
> 
> $ dovecot -n
> # 2.3.5.2 (38c8f1daf): /etc/dovecot/dovecot.conf
> # OS: Linux 3.10.0-957.10.1.el7.x86_64 x86_64 CentOS Linux release 7.6.1810 
> (Core)

Hi!

Apologies, the documentation lacked version information. Password grant will be 
available on 2.3.6 release.

Aki

OAuth Passdb Grant

[Tom via dovecot]

I'm trying to implement the password grant flow, as specified at
https://wiki2.dovecot.org/PasswordDatabase/oauth2,
but am getting an error message. Can you please help?

auth: Fatal: oauth2 /etc/dovecot/dovecot-oauth2.token.conf.ext: Error in
configuration file /etc/dovecot/dovecot-oauth2.token.conf.ext line 1:
Unknown setting: grant_url

$ dovecot -n
# 2.3.5.2 (38c8f1daf): /etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-957.10.1.el7.x86_64 x86_64 CentOS Linux release 7.6.1810
(Core)