Re: auth: Warning: Event 0x1280fe20 leaked

[Timo Sirainen via dovecot]

On 17 Jul 2019, at 22.13, Jos Chrispijn via dovecot  wrote:
> 
> On 16-7-19 9:30, John Doe Vecot via dovecot wrote:
>> Lately I get some errors in my logfile, saying:
>> 
>> dovecot[72337]: auth: Warning: Event 0x1280fe20 leaked (parent=0x0): 
>> auth-client-connection.c:338: 1 Time(s)
> Same overhere; can someone pls explain?
> 

What's your doveconf -n? I suppose this is coming either when 
stopping/reloading, or maybe auth process stops when it's been idling for 1 
minute. Do you use Postfix/Exim (or something else) that authenticates via 
Dovecot?

Re: auth: Warning: Event 0x1280fe20 leaked

[Aki Tuomi via dovecot]

 
 
  
   
  
  
   
On 17/07/2019 22:13 Jos Chrispijn via dovecot  wrote:
   
   

   
   

   
   
On 16-7-19 9:30, John Doe Vecot via dovecot wrote:

   
   
Lately I get some errors in my logfile, saying:
dovecot[72337]: auth: Warning: Event 0x1280fe20 leaked (parent=0x0): auth-client-connection.c:338: 1 Time(s)

   
   Same overhere; can someone pls explain?
   thanks.
  
  
   
  
  
   It's a bug, but not a fatal one. Thank you for reporting it. Any extra information, such as surrounding log lines would be useful.
  
  
   ---
Aki Tuomi
   
 

Re: auth: Warning: Event 0x1280fe20 leaked

[Jos Chrispijn via dovecot]

On 16-7-19 9:30, John Doe Vecot via dovecot wrote:


Lately I get some errors in my logfile, saying:

dovecot[72337]: auth: Warning: Event 0x1280fe20 leaked (parent=0x0): 
auth-client-connection.c:338: 1 Time(s)


Same overhere; can someone pls explain?

thanks.

Re: Dovecot release v2.3.7

[Michael Grimm via dovecot]

Timo Sirainen via dovecot  wrote:
> On 13 Jul 2019, at 18.39, Michael Grimm via dovecot  
> wrote:

>> Now replication is working from my point of view, besides occational error 
>> messages like:
>> 
>> | imap-login: Error: file_ostream.net_set_tcp_nodelay(, TRUE) failed: 
>> Connection reset by peer
> 
> Here's the final fix for it:
> 
> https://github.com/dovecot/core/commit/25028730cd1b76e373ff989625132d526eea2504

No wonder, after applying your patch those error messages are history :-)

Thank you very much and regards,
Michael

@Larry: from my point of view you may replace this patch with the previous one.

Re: pigeonhole question: filtering on delivered-to in case of fetchmail

[@lbutlr via dovecot]

> On 17 Jul 2019, at 10:03, Trever L. Adams via dovecot  
> wrote:
> 
>> On 15 Jul 2019, at 18:11, Trever L. Adams via dovecot > > wrote:
>> >
>>  So, one of the problems I am seeing is that people are trying to fake
>> 
>> >
>>  users into revealing information by sending from an outside domain but
>> 
>> >
>>  with an internal reply to address and claiming to be administration, IT
>> 
>> >
>>  or what not.
>> 
>> 
>> You should not accept external mail claiming to be from your domain unless 
>> that mail comes via authenticated submission. But if the reply to is going 
>> to an internal address… 
>> 
>> I’m puzzled by exactly what you mean here. Are you saying that users on your 
>> system are trying to phish other users on your system?
>> 
>> >
>>  I can set up something that will reject if from is outside the domain by
>> 
>> >
>>  reply to is internal. The problem is in some setups, there are fetchmail
>> 
>> >
>>  setups. I do not want to reject these with a message. Which is what I am
>> 
>> >
>>  currently doing for the others. Maybe I should discard them all without
>> 
>> >
>>  rejecting.
>> 
>> 
>> I haven’t used fetch mail in many many years, so I can’t answer anything 
>> specifically about it, but if you use it to allow external senders to send 
>> mail via your system in a way that is not authenticated then you should not 
>> do that.
>> 
> I do NOT allow email claiming to be from my domains. The problem is "forgery" 
> of Reply-To headers. 

People are forging reply-to headers to go to local addresses on your system? 
What is the possible motivation to that? Anyone replying will not reach the 
spammer/phisher.

> Some nonsense about having failed to follow directions and if I don't click 
> the link below, the account would be deleted. It was NOT talking about an 
> account on another system, but the email account itself.

Ah, I see what the problem is now. This is a job for SpamAssassin. Or a milter 
to strip URLs )or render them uunlcikable) to external domain from animal with 
a reply-to-header in your domain. But what email clients show reply-to and not 
From? Heck, don't most mail clients not show reply-to at all?

> So, as you see, it is coming from an outside domain. As the sieve code 
> showed, I am testing for where reply-to claims to be for internal domain, but 
> the from is NOT from it. This email was a good example of that.

Yes, sieve would be ideal for this as it’s very easy to match that and then 
feed the message to your bayes filtering, but you have to make exceptions for 
mailing lists,a s they often have a from and a reply-to that are different.

I don’t think I’ve seen this behavior, and I still find it a bit weird. 


-- 
BILL: I can't get behind the Gods, who are more vengeful, angry, an
dangerous if you don't believe in them!
HENRY: Why can't all these God just get along? I mean, they're
omnipotent and omnipresent, what's the problem?

Re: pigeonhole question: filtering on delivered-to in case of fetchmail

[Trever L. Adams via dovecot]

> On 15 Jul 2019, at 18:11, Trever L. Adams via dovecot  > wrote:
> >/So, one of the problems I am seeing is that people are trying to fake 
> >/>/users into revealing information by sending from an outside domain but 
> >/>/with an internal reply to address and claiming to be administration, IT 
> >/>/or what not. /
> You should not accept external mail claiming to be from your domain unless 
> that mail comes via authenticated submission. But if the reply to is going to 
> an internal address… 
>
> I’m puzzled by exactly what you mean here. Are you saying that users on your 
> system are trying to phish other users on your system?
>
> >/I can set up something that will reject if from is outside the domain by 
> >/>/reply to is internal. The problem is in some setups, there are fetchmail 
> >/>/setups. I do not want to reject these with a message. Which is what I am 
> >/>/currently doing for the others. Maybe I should discard them all without 
> >/>/rejecting. /
> I haven’t used fetch mail in many many years, so I can’t answer anything 
> specifically about it, but if you use it to allow external senders to send 
> mail via your system in a way that is not authenticated then you should not 
> do that.

I do NOT allow email claiming to be from my domains. The problem is
"forgery" of Reply-To headers. It isn't really forgery as far as I know
there is now method to check this anywhere. People are allowed to put
what they want there. The setups in question do NOT allow
unauthenticated submission with a FROM from the internal domain.

I have erased the email in question, so I cannot give an exact example
but it is something like this:

From: someth...@devcubesomething.org (I remember cube and dev in the domain)

To: trever@thedomain (yes it was sent to me, thankfully not one of the
other users)

Reply-To: info@thedomain (yes, stupid account to use, but that was it)

Subject: Your account will be deleted/deactivated

Some nonsense about having failed to follow directions and if I don't
click the link below, the account would be deleted. It was NOT talking
about an account on another system, but the email account itself.


So, as you see, it is coming from an outside domain. As the sieve code
showed, I am testing for where reply-to claims to be for internal
domain, but the from is NOT from it. This email was a good example of that.



signature.asc
Description: OpenPGP digital signature

Re: Dovecot release v2.3.7

[Tom Sommer via dovecot]

On 2019-07-16 09:46, Timo Sirainen via dovecot wrote:

> On 13 Jul 2019, at 14.44, Tom Sommer via dovecot  wrote:
> 
>> LMTP is broken on director:
>> 
>> Jul 13 13:42:41 lmtp(34824): Panic: file smtp-params.c: line 685 
>> (smtp_params_mail_add_body_to_event): assertion failed: ((caps & 
>> SMTP_CAPABILITY_8BITMIME) != 0)
> 
> Thanks, fixed: 
> https://github.com/dovecot/core/commit/c4de81077c11d09eddf6a5c93676ee82350343a6

Thanks. Is there a new release?

Re: Dovecot v2.3.7 - TLS/SSL issue

[Timo Sirainen via dovecot]

On 17 Jul 2019, at 13.59, Christos Chatzaras via dovecot  
wrote:
> 
> I use a helpdesk system that connects to dovecot using POP3 with SSL enabled 
> to fetch the e-mails.
> 
> After I upgrade to v2.3.7 the helpdesk randomly (some times it works, some 
> times not) doesn't fetch the e-mails. If I configure the e-mail accounts with 
> SSL/TLS disabled then it works.
> 
> Any idea about this?

What was the previous version you were using? Can you send log files about the 
time when it was broken? (You can send them to me privately.)

Dovecot v2.3.7 - TLS/SSL issue

[Christos Chatzaras via dovecot]

I use a helpdesk system that connects to dovecot using POP3 with SSL enabled to 
fetch the e-mails.

After I upgrade to v2.3.7 the helpdesk randomly (some times it works, some 
times not) doesn't fetch the e-mails. If I configure the e-mail accounts with 
SSL/TLS disabled then it works.

Any idea about this?

Re: [ext] 2.3.7 slower than 2.3.6?

[Ralf Hildebrandt via dovecot]

> > All of the data is an /dev/sda1
> 
> What filesystem is this?

ext4
 
> I did a bunch of testing, and after initially thinking I saw an
> increase it was just due to bad testing because the new TCP_NODELAY
> changes allowed imaptest to do more work. So I can't see that there is
> any disk IO difference.
> 
> There are a few intentional changes to lib-index and also mdbox
> code. One of those is that dovecot.index.cache files are being
> recreated more often now. In some cases they were wasting a lot of
> disk space because expunged mails hadn't been removed from them. I
> guess it's a possibility that all the disk IO was because in your
> system Dovecot started recreating all those files at the same time.
> Maybe you could try upgrading again during slower hours and see if the
> disk IO normalizes after a while?

Still running 2.3.7. 

Looking at the disk IO graphs today's IO usage looks OK!

I restarted dovecot yesterday after fixing the FTS settings:
Jul 16 10:14:45 mail-cbf dovecot: master: Dovecot v2.3.7 (494d20bdc) starting 
up for imap, lmtp (core dumps disabled)

after that I saw quite a bit of IO on sda1 (a bit of data read, lot of write),
which subsided at11:30

After that diskio was low, up to the present day.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

Re: [ext] 2.3.7 slower than 2.3.6?

[Timo Sirainen via dovecot]

On 16 Jul 2019, at 11.15, Ralf Hildebrandt via dovecot  
wrote:
> 
> * Timo Sirainen via dovecot :
> 
>>> And alas, I had a look at the monitoring and found that disk IO has
>>> increase A LOT after the update: 
>>> https://www.arschkrebs.de/images/dovecot-disk-io-increase.png
>>> 
>>> I zoomed in and found that the sudden increace in IO coincides with
>>> the update to 2.3.7 (14:35): 
>>> https://www.arschkrebs.de/images/dovecot-io-2.png 
>>> 
>> 
> 
>> Do the different disks have different kinds of data? 
> 
> All of the data is an /dev/sda1

What filesystem is this?

I did a bunch of testing, and after initially thinking I saw an increase it was 
just due to bad testing because the new TCP_NODELAY changes allowed imaptest to 
do more work. So I can't see that there is any disk IO difference.

There are a few intentional changes to lib-index and also mdbox code. One of 
those is that dovecot.index.cache files are being recreated more often now. In 
some cases they were wasting a lot of disk space because expunged mails hadn't 
been removed from them. I guess it's a possibility that all the disk IO was 
because in your system Dovecot started recreating all those files at the same 
time. Maybe you could try upgrading again during slower hours and see if the 
disk IO normalizes after a while?