debugging file permissions wrong
Hi, In trying to debug a strange error where client can't login, I enabled all the usual debug settings, this is all good, it works for imap and pop3 fine, but the problem is when used with dovecot's LDA there is a nasty issue. the file created by debug_log_path in this case /var/log/dovecot/debug.log , this file created as root, again this is fine for nice logging of imap and pop3, but this causes postfix not to deliver mail, for write permission denied, LDA runs as vmail, all my sub sections like *_listener also = vmail and all my uid/gid settings are also to user/group vmail obviously you wont main log files to not be owned by vmail for case of security, so is there a way to set the ownership of the debug file - apart from the obvious of remembering 40 minutes later when you get alert of high mailq level to chown the file :) If there is no way, may the developers take this as a feature request please. Thanks Loz
Re: debugging file permissions wrong
Hi, Yes, lda writes to deliver.log just fine, will give type syslog a try, was just hoping to put it into a debug file so when we sort out the issue we can delete the file without losing correct metadata entries On Tue, Jun 1, 2021 at 3:26 PM Aki Tuomi wrote: > > > On 01/06/2021 02:35 Laura Steynes wrote: > > > > > > Hi, > > > > In trying to debug a strange error where client can't login, I enabled > all the usual debug settings, this is all good, it works for imap and pop3 > fine, but the problem is when used with dovecot's LDA there is a nasty > issue. > > > > the file created by debug_log_path in this case > /var/log/dovecot/debug.log , this file created as root, again this is fine > for nice logging of imap and pop3, but this causes postfix not to deliver > mail, for write permission denied, LDA runs as vmail, all my sub sections > like *_listener also = vmail and all my uid/gid settings are also to > user/group vmail > > > > obviously you wont main log files to not be owned by vmail for case of > security, so is there a way to set the ownership of the debug file - apart > from the obvious of remembering 40 minutes later when you get alert of high > mailq level to chown the file :) > > > > If there is no way, may the developers take this as a feature request > please. > > Thanks > > Loz > > dovecot-lda should be using log process to write logs, as i'm sure you are > getting the non-debug kind of logs just fine from lda, right? > > One way to workaround this would be to use debug_log_path=syslog to write > logs via syslog socket. > > Aki >
Re: debugging file permissions wrong
Aki, using syslog works, but using the file does not, the exact error is in deliver log - where lda writes to ok lda: Fatal: Can't open log file xxx: Permission denied so log files deliver.log owned by vmail/vmailand pop3 log root/root, the debug file is created root/root but lda is vmail user so of course perm denied. protocol lda is not told any user, just path, I guess it gets its user perms from the entry in postfix master when it gets its first entry to write, it then creates it, as that user? Thats what it appears so we would need a way to set username on the debug command, as pop3 logout is done as root it will write anyway. On Wed, Jun 2, 2021 at 12:56 PM Laura Steynes wrote: > Hi, > Yes, lda writes to deliver.log just fine, will give type syslog a try, was > just hoping to put it into a debug file so when we sort out the issue we > can delete the file without losing correct metadata entries > > > On Tue, Jun 1, 2021 at 3:26 PM Aki Tuomi > wrote: > >> >> > On 01/06/2021 02:35 Laura Steynes wrote: >> > >> > >> > Hi, >> > >> > In trying to debug a strange error where client can't login, I enabled >> all the usual debug settings, this is all good, it works for imap and pop3 >> fine, but the problem is when used with dovecot's LDA there is a nasty >> issue. >> > >> > the file created by debug_log_path in this case >> /var/log/dovecot/debug.log , this file created as root, again this is fine >> for nice logging of imap and pop3, but this causes postfix not to deliver >> mail, for write permission denied, LDA runs as vmail, all my sub sections >> like *_listener also = vmail and all my uid/gid settings are also to >> user/group vmail >> > >> > obviously you wont main log files to not be owned by vmail for case of >> security, so is there a way to set the ownership of the debug file - apart >> from the obvious of remembering 40 minutes later when you get alert of high >> mailq level to chown the file :) >> > >> > If there is no way, may the developers take this as a feature request >> please. >> > Thanks >> > Loz >> >> dovecot-lda should be using log process to write logs, as i'm sure you >> are getting the non-debug kind of logs just fine from lda, right? >> >> One way to workaround this would be to use debug_log_path=syslog to write >> logs via syslog socket. >> >> Aki >> >
lda to lmtp
Hi, Although dovecot-lda serves us fine, we only average 8k messages an hour, peaking at 11k, over 4 machines (mostly for redundancy, we've run this fine on just 1 machine, but sometimes clamav makes things get upset, so we added some more especially since we are growing rapidly, we decided to see if lmtp would be of benefit, so far, we cant tell any difference, I guess it is only 120-130 messages a minute, maybe if we were doing 200 a minute we might see gain? The question is with lda we used postfix settings destination_recipient_limit=1, we have not added this with lmtp,is this needed?
possible minor bug: lmtp excessice newlines
Aki, unnecessary newlines in lmtp received header? Received: from mail6.xx.com by mail6.xxx.com with LMTP id xx (envelope-from ) for ; Sat, 05 Jun 2021 14:19:07 +0100 is this intentional Aki ? Evident is multiple clients, in widescreen, so is inot client squashing the header # Dovecot version 2.3.14 # Pigeonhole version 0.5.14 # OS: Linux 5.10.41 x86_64
Re: lda to lmtp
so nobody On Sun, Jun 6, 2021 at 12:03 PM Laura Steynes wrote: > Hi, > Although dovecot-lda serves us fine, we only average 8k messages an hour, > peaking at 11k, over 4 machines (mostly for redundancy, we've run this fine > on just 1 machine, but sometimes clamav makes things get upset, so we > added some more especially since we are growing rapidly, we decided to see > if lmtp would be of benefit, so far, we cant tell any difference, I guess > it is only 120-130 messages a minute, maybe if we were doing 200 a minute > we might see gain? > > The question is with lda we used postfix settings > destination_recipient_limit=1, we have not added this with lmtp,is this > needed? > >
Re: Dovecot v2.3.15 released
I know I'm blonde so might be silly question, but this libsystemd
dependency, does this mean dovecot need it mandatory even if we do not use
a systemd infected OS ? Or is it only needed if we use one of those systemd
infected OS's?
My question is because our linux does not use systemd
Thanks
On Mon, Jun 21, 2021 at 9:19 PM Timo Sirainen wrote:
> Hi,
>
> Here's a new release with some security fixes and quite a lot of other
> changes as well.
>
> https://dovecot.org/releases/2.3/dovecot-2.3.15.tar.gz
> https://dovecot.org/releases/2.3/dovecot-2.3.15.tar.gz.sig
>
> Binary packages in https://repo.dovecot.org/
> Docker images in https://hub.docker.com/r/dovecot/dovecot
>
> * CVE-2021-29157: Dovecot does not correctly escape kid and azp fields in
>JWT tokens. This may be used to supply attacker controlled keys to
>validate tokens, if attacker has local access.
> * CVE-2021-33515: On-path attacker could have injected plaintext commands
>before STARTTLS negotiation that would be executed after STARTTLS
>finished with the client.
> * Disconnection log messages are now more standardized across services.
>They also always now start with "Disconnected" prefix.
> * Dovecot now depends on libsystemd for systemd integration.
> * Removed support for Lua 5.2. Use version 5.1 or 5.3 instead.
> * config: Some settings are now marked as "hidden". It's discouraged to
>change these settings. They will no longer be visible in doveconf
>output, except if they have been changed or if doveconf -s parameter
>is used. See https://doc.dovecot.org/settings/advanced/ for details.
> * imap-compress: Compression level is now algorithm specific.
>See https://doc.dovecot.org/settings/plugin/compress-plugin/
> * indexer-worker: Convert "Indexed" info logs to an event named
>"indexer_worker_indexing_finished". See
>
> https://doc.dovecot.org/admin_manual/list_of_events/#indexer-worker-indexing-finished
> + Add TSLv1.3 support to min_protocols.
> + Allow configuring ssl_cipher_suites. (for TLSv1.3+)
> + acl: Add acl_ignore_namespace setting which allows to entirely ignore
>ACLs for the listed namespaces.
> + imap: Support official RFC8970 preview/snippet syntax. Old methods of
>retrieving preview information via IMAP commands ("SNIPPET and PREVIEW
>with explicit algorithm selection") have been deprecated.
> + imapc: Support INDEXPVT for imapc storage to enable private
>message flags for cluster wide shared mailboxes.
> + lib-storage: Add new events: mail_opened, mail_expunge_requested,
>mail_expunged, mail_cache_lookup_finished. See
>https://doc.dovecot.org/admin_manual/list_of_events/#mail
> + zlib, imap-compression, fs-compress: Support compression levels that
>the algorithm supports. Before, we would allow hardcoded value between
>1 to 9 and would default to 6. Now we allow using per-algorithm value
>range and default to whatever default the algorithm specifies.
> - *-login: Commands pipelined together with and just after the
> authenticate
>command cause these commands to be executed twice. This applies to all
>protocols that involve user login, which currently comprises of imap,
>pop3, submisision and managesieve.
> - *-login: Processes are supposed to disconnect the oldest non-logged in
>connection when process_limit was reached. This didn't actually happen
>with the default "high-security mode" (with service_count=1) where each
>connection is handled by a separate process.
> - *-login: When login process reaches client/process limits, oldest
>client connections are disconnected. If one of these was still doing
>anvil lookup, this caused a crash. This could happen only if the login
>process limits were very low or if the server was overloaded.
> - Fixed building with link time optimizations (-flto).
> - auth: Userdb iteration with passwd driver does not always return all
>users with some nss drivers.
> - dsync: Shared INBOX not synced when "mail_shared_explicit_inbox" was
>disabled. If a user has a shared mailbox which is another user's INBOX,
>dsync didn't include the mailbox in syncing unless explicit naming is
>enabled with "mail_shared_explicit_inbox" set to "yes".
> - dsync: Shared namespaces were not synced with "-n" flag.
> - dsync: Syncing shared INBOX failed if mail_attribute_dict was not set.
>If a user has a shared mailbox that is another user's INBOX, dsync
>failed to export the mailbox if mail attributes are disabled.
> - fts-solr, fts-tika: Using both Solr FTS and Tika may have caused HTTP
>requests to assert-crash: Panic: file http-client-request.c: line 1232
>(http_client_request_send_more): assertion failed: (req->payload_input
> != NULL)
> - fts-tika: 5xx errors returned by Tika server as indexing failures.
>However, Tika can return 5xx for some attachments every time.
>So the 5xx error should be retried once, but treated as success if it
modernizing dovecot.conf
Happy Holidays,
And if you like me are working throughout so more senior engineers get
their holidays, my condolences hah
Taking the time to bring our dovecot.conf into the 2021/22 era .since its
quiet time of year,
Do I read it right that where we have things like
service imap {
process_limit = 1024
executable = imap imap-postlogin
are not needed now ?
and process limit is a global option?
things like pop3/imap_client_workarounds = fooy
are now global options, not to be in protocol { } sections ?
I am reading the example conf files and see these outside the protocol
sections where they have in the past lived, this is what makes me think
they are now global and not needed in sub sections. but I may be missing
some linking going from file to file , we have forever updated our single
config file, just fixing whatever breaks when major versions break
something, easier to find options in one file, rather than trying to sift
through 40 included files like I am looking at now :-)
Re: modernizing dovecot.conf
That prints out what I have now, inside protcol sections, which differs from the config examples, so is of no use to my questions, thank you for trying anyway On Thu, Dec 30, 2021 at 1:13 PM Benny Pedersen wrote: > On 2021-12-30 03:34, Laura Steynes wrote: > > easier to find options in one file, rather > > than trying to sift through 40 included files like I am looking at now > > :-) > > you dont have spare times > > doveconf -n > > no need to read more > > if something should change to the better, it would be better default > config, that could lead to less questions on why and how to get xxx to > work, currect is not that much helpfull for setup new things with unless > we all are developpers sadly, and now that dovecot is not enterprise > anymore there is less support there aswell :( >
Re: modernizing dovecot.conf
Because gmail is dumb. good mail client interfaces see reply-all with a mailing list as reply to list only I'll await someone more knowledgeable to answer my original questions I think On Thu, Dec 30, 2021 at 2:27 PM Benny Pedersen wrote: > On 2021-12-30 04:58, Laura Steynes wrote: > > That prints out what I have now, inside protcol sections, which > > differs from the config examples, so is of no use to my questions, > > thank you for trying anyway > > this is maillists, why did you reply privately aswell ?, more info ? > > HPNY all >
Question about mail_location
In using mysql, in the configuration file we need to specify, in the user query, '/path/ as home, yet but in dovecot.conf, we also are setting mail_location, the same thing is it not, so unless I've missed something, do we still need to use the path as home in the user query? Do we only need set that if it differs from mail_location? Thanks
Redirects 550'd So why no SRS method
Happy New Year! Now to Aki, Timo, Corr, why, when setting up mail forwarding, is sieve not automatically configuring rules for SRS, it has this ability for long time, yet dovecots sieve based forwarding just creates a plain old redirect "forward" resulting in,in 2024, 99% of forwarded emails getting rejected for failing SPF because it's not enabling the require or the rules needed for successful sender rewriting. Is this an oversight? and I suppose the bigger question is, when is it planned to be corrected to using SRS method? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
BUG: logging bug creeped back in pop3-login
Oct 20 14:23:29 pop3-login: Info: Disconnected: Disconnected: Too many bad commands (no auth attempts in 0 secs): use... Double logging of Disconnected ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: BUG: logging bug creeped back in pop3-login
# 2.3.21.1 (d492236fa0): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.21.1 (49005e73) On Mon, Oct 21, 2024 at 3:32 PM Aki Tuomi wrote: > > > On 21/10/2024 00:30 EEST Laura Steynes via dovecot > wrote: > > > > > > Oct 20 14:23:29 pop3-login: Info: Disconnected: Disconnected: Too many > bad > > commands (no auth attempts in 0 secs): use... > > > > Double logging of Disconnected > > What version of dovecot is this? > > Aki > ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Migrating GMail to Dovecot using imapc
On Wed, Nov 27, 2024 at 10:31 PM Marc wrote: > > > > > > > > > > > > > Try sending a spam message that Gmail sends you, back to them and > > see > > > > what happens. > > > > > > > > > > It is even worse, they just accept emails with stat=Sent and then > > delete > > > emails without notifications. I am currently trying to get the EU to > > take > > > such behaviour into their market abuse cases. > > > > > > Plenty of us do that, SENT just means you passed blacklists, doesn't > > mean > > you've passed spam checks. > > Incorrect Sent means the receiving server has correctly received the > transmitted message. It has nothing to do with spam or not spam. > > I more or less said that, you are a mail administrator yes? then you know bloody damn well that 99% of spam checks are carried out after reception of the mail.go find a child and ask them to explain what I wrote you Besides it is very uncommon to delete messages without any notifications to > sender or recipient. You are processing someone else's data, so I would say > it is even unethical to just dump stuff. > uncommon? what planet are you on, look now I *know* you are trolling, go away you foolish person. Seriously, dick head do not reply to me or send me any more personal emails. *PLONK* ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Migrating GMail to Dovecot using imapc
On Tue, Nov 26, 2024 at 8:14 PM Marc wrote: > > > > > > Maybe that is in your opinion because you can not send him direct mail? > > Why > > No, it is not an opinion it is a fact. That is the huge difference here. > There is some sort of logic in my reasoning, while ignoring false positives > and working with old data has little. > > In your opinion, like most of us here who run a service for others, we make the decisions on what blacklists we use, what anti spam rules we use, we decide to use DMARC and block failures, if he or anyone runs other tests, so be it, who are you or I to say its wrong, it's not, it's just _different_ > > To outsiders this is kind of cryptic, but sounds like you failed DNS > > testing that Noel uses in making an accept/reject decision so he is > > blocking you? > > His data is old and incorrect. Since when has a dns configuration to do > with spam? From my experience it is often that such weird measures are > created out of a lack of ability to really address and implement a targeted > solution. > > I guess this relates to the zonecheck.org you mentioned? So your DNS was more messed up than this? DELEGATION ERROR IP 87.233.156.132 refers to multiple nameservers ( ns1.roosit.com; ns1.roosit.nl). DELEGATION ERROR IP 87.233.156.133 refers to multiple nameservers ( ns2.roosit.com; ns2.roosit.nl). DELEGATION ERROR Parent has nameserver(s) not listed at the child ( ns1.roosit.com; ns2.roosit.com). DELEGATION ERROR None of the nameservers listed at the parent are listed at the child. CONNECTIVITY WARNING All authoritative nameservers have their IPv4 addresses in the same AS (15703 The following name server(s) are announced in the same IPv4 prefix ( 87.233.128.0/18): "ns1.roosit.com/87.233.156.132; ns1.roosit.nl/87.233.156.132; ns2.roosit.com/87.233.156.133; ns2.roosit.nl/87.233.156.133" You're right, zonecheck information is wrong, it says the same /18 but goodness me, it's in the same /24 which is worse, since nobody accepts BGP prefixes less than 24, so both your DNS servers are gone if your routes flap. He can't even prove there was spam send from this network. If I block a > network, I at least make sure we have original message and store it. So we > can say "Your network send this on that date". > > Why does anyone have to prove anything to you? That's right, nobody does, if he blocks more than a /32 thats his choice, I'm sure I read he say something about others in your IP range, perhaps he played wack a mole game then decided to stop wasting his time and blacklists the /24 >So rather than sit here generating noise, making this > > original thread useless now, you go fix you DNS problems and who knows, > > maybe you won't get blocked, if you are not going to do that, live with > > your decision and move on so this thread can get back to normal. > > > > Up until now I did not notice much expertise from you, for me to take your > advises. Besides, this does illustrate the 'irrationality' and lack of > innovative thinking in smaller companies which drives people into the > direction of large providers like gmail and outlook.com > > I've been on here, postfix, NANOG and a bunch of lists for many years, I don't post for the sake of posting like some. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Migrating GMail to Dovecot using imapc
On Wed, Nov 27, 2024 at 3:53 AM Marc wrote: > > > > > Try sending a spam message that Gmail sends you, back to them and see > > what happens. > > > > It is even worse, they just accept emails with stat=Sent and then delete > emails without notifications. I am currently trying to get the EU to take > such behaviour into their market abuse cases. > > Plenty of us do that, SENT just means you passed blacklists, doesn't mean you've passed spam checks. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Migrating GMail to Dovecot using imapc
Hi Scott, On Sat, Nov 30, 2024 at 2:10 AM Scott Q. wrote: > I see this thread is getting quite personal, but if I may comment on > something you wrote. > > >> I more or less said that, you are a mail administrator yes? then you > know bloody damn well that 99% of spam checks are carried out after > reception of the mail > > depends what you define by reception. We perform spam checks on the DATA > portion of the mail reception and can refuse a message in that segment. > Therefore, spam check is done on the message before accepting it. > > TLDR: reasonableness for testing in DATA depends on your traffic levels LV: I understand some small players may do this, however most don't, In my "part-time contractor role" outside of my day-job, nearly everyone uses postfix/amavisd/dovecot in the years I've seen nearly none of them use milters to test they accept it then hand it off to spamassassin via amavisd, even of the couple of exim installs I've worked on, only one used a weird integration that tested in DATA, but as a small law firm they weren't high traffic so can do that. In my regular day-job role as network administrator for a ISP, and 2 other ISP's over past 16 years, none have done this, these ISP's are in Asia and U.S., if a message is accepted it then passed on to anti spam measures, including current employer who operates 14 inbound MX's alone, they are no gmail or outlook but are high traffic where each inbound machine processes around 360 connections per minute, you do the sums on the amount of delays that will incrementally occur testing in DATA to still deliver mail in reasonable time after received, won't take long before those machines are to be running way behind and trigger Hi-Q alerts. Loz ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Migrating GMail to Dovecot using imapc
On Sat, Nov 30, 2024 at 11:01 PM Scott Q. wrote: > Replace SA by rspamd ? SA is unbearably slow. You have 14 mx hosts, get 14 > rspamd vhosts and I doubt you'll have any issues. > > Scott > > Oh, I never said we at dayjob use spamassassin :D That was at most places I do my moonlight contracting with, and they are small businesses so no big traffic levels and SA seems snappy enough, we here at dayjob did look at rspamd about 3 years back, did some tests, we found it slower than what we use today, we also found it on par with spamassassin milter, although both slightly faster than spammassasin with amavisd, perhaps rspamd has much improved since 3 years, If it has I'd like to see some independent test results, as we need a serious compelling reason to modify what we know works very well and resource happy. Must be off kids are complaining they'll be late for sport, sport be damned, it's minus10 outside! They run around whilst I get pneumonia :D Have good weekend. Loz ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Migrating GMail to Dovecot using imapc
On Mon, Nov 25, 2024 at 10:34 PM Marc via dovecot wrote: > > > > > But now you are like ms/google/letsencrypt. We decide how you should > > > setup your servers, we decide how you setup your dns, we decide you > > are > > > not allowed to block the amazon cloud etc. > > > > WTF drugs are you on, my organisation my rules. > > > > What education did you acquire? With your logics you configure your spam > servers like this "I don't want to receive spam, so if the last octet of > the connecting ip is uneven, I will block it" > > ISP's do this all the time, welcome to the internet! > and who said anything about not allowed to block amazon, I have a couple > > of amazon class C's blacklisted here, dont answer that, it was a > > rhetorical statement. > > > > > No way to little volume. You should focus on that this system is not > > > updating its data, maybe because it is on a shared network that is > > > being blocked because of unnecessary scraping? > > > > This is off topic, so for my last... > > > > I dont care how big or little ones volume is, it's the quality thats > > taken into account, and if you're on a shared IP, its the risk that you > > elect to take, that aint my problem, have a great week. > > > > Your system reporting false positives, that is what I am trying to tell > you! > > Maybe that is in your opinion because you can not send him direct mail? Why are you sending him direct mail anyway? This is a mailing list, you should only be replying to the list. To outsiders this is kind of cryptic, but sounds like you failed DNS testing that Noel uses in making an accept/reject decision so he is blocking you? So rather than sit here generating noise, making this original thread useless now, you go fix you DNS problems and who knows, maybe you won't get blocked, if you are not going to do that, live with your decision and move on so this thread can get back to normal. Lozza ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
