Re: Call procmail after sieve

[Bernd Petrovitsch]

Hi all!

On 31/08/2022 11:40, George Asenov wrote:
[...]> Aug 30 15:22:26 uk7 dovecot[112153]:
lda(test-uk7.teststring567.tk)<112151>: Fatal: 
execvp(/var/lib/dovecot/sieve-pipe/procmail) failed: Permission denied


That looks like a permission problem - no x Bits set on the executable
and/or directories to it (for the dovecot user)?

Kind regards,
Bernd
--
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at

Re: Sieve Rule help

[Bernd Petrovitsch]

Hi all!

On 15/08/2021 14:25, Jorge Bastos wrote:
[...]
> Thanks for helping me understand it better.

De nada, you're welcome. My sieve file for mail filtering
is 51KB large BTW and looks basically like your stuff up
in the thread ...

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at

Re: Sieve Rule help

[Bernd Petrovitsch]

Hi all!

On 15/08/2021 11:46, Jorge Bastos wrote:
[...]
> I have an user with the rule below.
> Since it's discarding the match first, should it be stop there and don't
> redirect it to the next rule?

No, why should it?
Put a "stop" after it (like in the second rule).

> Thanks in advanced,
> 
> ###
> 
> require ["date","relational","vacation"];
> # rule:[xxx]
> if header :contains "from" "icnf.pt"
> {
> discard;
> }
> # rule:[redir]
> if true
> {
> redirect "jo...@myemail.pt";
> stop;
> }

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Bernd Petrovitsch]

Hi all!

On 01/08/2021 23:24, Aki Tuomi wrote:
>> On 01/08/2021 23:44 Michael Orlitzky  wrote:
[...]
>> On Sun, 2021-08-01 at 21:53 +0300, Mart Pirita wrote:
>>>
>>> As Docvecot does not support INC_PATH= and ignores --includedir= option, 
>>
>> You can try CPPFLAGS="-I" in the future. I don't know how a
>> normal person would ever figure it out, but that's the "correct" way to

Just write Makefiles (or read the docs of `make`);-)

>> include headers from a non-default directory.
> 
> That's a feature of autoconf, documented in e.g. 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Preset-Output-Variables.html.
>  You can use ./configure ... EXTRA_CFLAGS or CPPFLAGS. The EXTRA_CFLAGS is 
> dovecot specific.

CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS, LDLIBS (and a lot more) are
actually used/defined by the default rules of `make`.
autoconf just generates shell scripts and Makefiles as it uses
`make` ...

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at

Re: Sieve by the addressee

[Bernd Petrovitsch]

Hi all!

On 20/02/2021 19:02, Shawn Heisey wrote:
> On 2/20/2021 8:50 AM, Markus Schönhaber wrote:
>> I consider it a better idea to filter mailing list messages by their
>> List-ID header.
> 
> I agree with Markus.  It's what I do.  This works well:
> 
> if header :regex "list-id" "solr-user.lucene.apache.org"

I use :contains or :is ...

> {
>     fileinto "asf.solr-user";
>     stop;
> }
> 
> I do not know if List-ID is common to all mailing list software, but

It should be - RFC2919 defines it and at least mailman set's it.

> even if it's not, there should be something available in the message
> headers that you can use.

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at

Re: Sieve filter script EXECUTION FAILED

[Bernd Petrovitsch]

On Fri, 2020-10-30 at 12:21 -0600, @lbutlr wrote:
> On 30 Oct 2020, at 11:25, Bernd Petrovitsch  wrote:
> > On 30/10/2020 17:11, @lbutlr wrote:
> > [...]
> > > echo $1 | sed -e '||* {color:white !important; 
> > > background-color: black !important; } |'
> > 
> > What should the sed stuff do?
> 
> Changes  to * {color:white !important; background-color: black 
> !important; } 
> 
> > TTBOMK '|' is not known by sed ...
> 
> Yes, it most certainly is.

Perhaps try the script beforehand in a terminal:
  snip  
{2}sed -e '|x|y|'
sed: -e expression #1, char 1: unknown command: `|'
  snip  
So no, it's not.

You actually wanted:
  snip  
echo $1 | sed -e 's||* {color:white !important; background-color: 
black !important; } |'
  snip  

Or just use bash (and avoid anorther fork()+exec()):
  snip  
#!/bin/bash --norc
echo ${1/<\/head>/

Re: Sieve filter script EXECUTION FAILED

[Bernd Petrovitsch]

On Fri, 2020-10-30 at 19:57 +0200, Aki Tuomi wrote:
> > On 30/10/2020 19:25 Bernd Petrovitsch  wrote:
> > 
> >  
> > On 30/10/2020 17:11, @lbutlr wrote:
> > [...]
> > > echo $1 | sed -e '||* {color:white !important; 
> > > background-color: black !important; } |'
> > 
> > What should the sed stuff do?
> > TTBOMK '|' is not known by sed ...
> > 
> > MfG,
> > Bernd
> 
> sed accepts | as alternative for / as boundary.

GNU-sed accepts (almost?) all characters as boundary for s/from/to/ ...

> But I think the sed here is missing 's' from start, so this does not actually 
> do anything...

We can only guess what was actually meant ...

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
 LUGA : http://www.luga.at

Re: Sieve filter script EXECUTION FAILED

[Bernd Petrovitsch]

On 30/10/2020 17:11, @lbutlr wrote:
[...]
> echo $1 | sed -e '||* {color:white !important; 
> background-color: black !important; } |'

What should the sed stuff do?
TTBOMK '|' is not known by sed ...

MfG,
Bernd
-- 
There is no cloud, just other people computers.
-- https://static.fsf.org/nosvn/stickers/thereisnocloud.svg


pEpkey.asc
Description: application/pgp-keys

Re: Version controlled (git) Maildir generated by Dovecot

[Bernd Petrovitsch]

Hi all!

On 07/10/2020 14:45, David Myers wrote:
[...] 
> Just for completions sake, and in case someone else comes here in the future;

+1!

> This is a link to the current (2020 LO 7) wiki page describing the XML format 
> .
> 
> However it doesn't mention about being able to save a document directly as 
> its constituent XML docs ??? so maybe the function has been removed, I have 
> miss remembered, or I am going mad (I vote for the 4th option ;) ).

In e.g. localc, you can "save as" an select at the bottom
right "Flat XML ODF Spreadsheet (.fods)".

The same exists in lowriter (and very probably in all
others - I didn't use them up to now).

Mfg,
Bernd
-- 
There is no cloud, just other people computers.
-- https://static.fsf.org/nosvn/stickers/thereisnocloud.svg


pEpkey.asc
Description: application/pgp-keys

Re: Ms Exchange vs dovecot

[Bernd Petrovitsch]

On Fri, 2020-05-08 at 22:17 +0200, Marc Roos wrote:
> I have recently been working/testing with exchange 2016 and started 
> thinking if I should even migrate to this platform. I assume more people 
[...]

I assume you are aware of https://en.wikipedia.org/wiki/CLOUD_Act
so using software from (heavily) US-based companies
implies that all data (controlled by said companies) will -
sooner or later - end up in the databases of
US-3-letter-organizations.

So forget about GDPR compliance with such software
providers.

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
 LUGA : http://www.luga.at

Re: dovecot rejecting connects

[Bernd Petrovitsch]

Hi all!

On Fri, 2019-12-20 at 17:39 -0700, Roy wrote:
[...]
> I created a new VM with Centos 8 and installed dovecot and postfix.  
> Postfix is working fine but dovecot rejects connections from anything 
> but the local machine.
> 
> Locally
> 
>Trying 10.10.100.157...
>Connected to 10.10.100.157.
>Escape character is '^]'.
>* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE 
> IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
> 
> Machine on same subnet.  Windows, Linux, etc.  Doesn't seem to matter
> 
>telnet 10.10.100.157 143
>Connecting To 10.10.100.157...
>Could not open connection to the host, on port 143: Connect failed
> 
> I made sure the iptables are empty so it doesn't seem to be a firewall issue

In the host or the VM?
Is teh VM switchted or routed with the LAN interface?

> I put some LOG statements in the iptables and it showed the connect 
> packet arriving and the response packet was ICMP type 3 code 13.

Which make it pretty clear that it has nothing to do with
dovecot as such as that's aresponse from the TCP/IP-stack ...

> Any ideas?

Duckduckgo-ing "icmp 3 13" delivers as the 1st link
http://www.networksorcery.com/enp/protocol/icmp/msg3.htm and
13 seem to indicate "Communication Administratively Prohibited."

Your turn;-)

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: Ticket Received - [#22073] Re: Duplicate e-mail with Dovecot and Sieve

[Bernd Petrovitsch]

Hi all!
On 11/12/2019 19:16, Benny Pedersen via dovecot wrote:
> Atomia via dovecot skrev den 2019-12-11 17:37:
[...]
> wonderfull example on why mailman sooks on change sender from ://

Reply-to munging is considered harmful - please fix that.
And thunderbird shows in the "From", "Recipient", "Correspondents" and
"Sender[@]" column only "dovecot@dovecot.org" which neither helpful nor
correct.

[...]

Mfg,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: http API for IMAP

[Bernd Petrovitsch via dovecot]

Hi all!

On 15/11/2019 14:06, Thomas Güttler via dovecot wrote:
[...]
>> Note that smtpjs uses a service located at http://smtpjs. It's not truly a 
>> Javascript SMTP client. This "utility" means you are uploading your email 
>> credentials to the server smtpjs.com. Use with extreme caution.

You really wanted to write here: You really don't want to use
that unless you are http://smtpjs or drive your honey pot with
specially created accounts.

MfG,
Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds


pEpkey.asc
Description: application/pgp-keys

Re: Spam Blocking by filtering on username / id

[Bernd Petrovitsch via dovecot]

On 23/09/2019 07:29, Plutocrat via dovecot wrote:
> This is probably quite an easy question, but I haven't been able to
> find the answer. I'm running a server where all the email addresses
> are in the format "u...@domain.com". I've noticed that a large number
> of fake login attempts use the format "user" eg. reception, service,
> root, admin. 
> > Is it possible to prevent any such logins to these email users
> > without
an @domain.com? Or maybe ignore them. Or drop them from the logging.

It's not directly a solution within dovecot but "fail2ban" exists.

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Bug] Sieve vacation :addresses match only,> case-sensitive?

[Bernd Petrovitsch via dovecot]

On 11/09/2019 22:43, Hendrik Boom via dovecot wrote:
> On Wed, Sep 11, 2019 at 09:25:54PM +0200, Klaus Steinberger via dovecot wrote:
>>> I want to have it case-insensitive again, like in Pigeonhole version 0.4.24
>>
>> i would also plea for making it case-insensitive again! We were hit by this 
>> too,
>> and I never saw any mail system in which the local Part ist Case sensitive!

E.g.
https://stackoverflow.com/questions/9807909/are-email-addresses-case-sensitive
discusses this - including quotes from RFCs ...

> Isn't the user name in the original Unix mail system (and presumably 
> most of its descentants) case sensitive?  In which case it has to 
> distinguish between mail sent to bob and to Bob?

The local part of an email domain has absolutely nothing to do with any
(local or non-local) user account - and who says that there are any user
accounts/logins (apart from root and so-called system users) on the mail
system?
Yes, it *could* have something to do, and yes it actually may often be
the case but that's just a - intended or not intended - coincidence 

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: gcc -> clang

[Bernd Petrovitsch]

Hi all! On 03/01/2019 10:50, Rupert Gallagher via dovecot wrote:
> Please, use clang instead of gcc. Code quality can only profit from it.
> I just compiled 2.3.4 and compiler stderr is full of interesting problems. 

But obviously not interesting enough to share the clang command line and
the output from it.

MfG,
Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds


pEpkey.asc
Description: application/pgp-keys

Re: Mailing list address harvested for spamming

[Bernd Petrovitsch]

Hi!

On 02/12/2018 23:58, Noel Butler wrote:
> On 02/12/2018 11:00, Hendrik Boom wrote:
> 
>> There's an extensive email etiquette post somewhere on the net 
>> explaining why setting 'reply-to' to the list is a bad idea.
> 
> Lots of posts around about this, all self serving :) 
> 
> There may of course be an RFC floating around, but I admit to never
> having bothered to look, because good netizens reply to list, lists are

Good netizens also check and edit the To: and Cc: lines.

> public, they are for the masses - the membership - the subscriber base,
> never seen the point in replying privately to a list post, since the

Lots of people actually ignore private questions in such public
"environments" - simply because of the said reasons (and to make the
time more useful).

> answer deprives the list membership of, the answer, so you avoid getting
> 1500 people ask the same damn question. 

Especially since search engines make it much more easier to find
questions/problems and answers/solutions in mailing list archives.

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: Mailing list address harvested for spamming

[Bernd Petrovitsch]

On 02/12/2018 04:13, Ruben Safir wrote:
[...]
> Email should be intitive

(It was for me clear from the context that you meant "intuitive";-)

Yes, email (as any other tool) should be intuitive and as easy to use as
a hammer (and even hammers can be misused - it' just that we grow up and
learn how to use a hammer).
But with increasing complexity of a tool, this is gets harder an harder
to achieve.
And the main "problem" with user-interfaces as such is that a "good user
interface" depends on the user (the users knowledge, etc.) so an
intuitive user-interface for one user may be totally
non-intuitive/strange/ hard to use/inconvenient/too limiting/ for
another user (and vice versa).

And the solution is actually trivial: a MUA just needs always a "reply
to sender" and "reply to all" button and when the MUA detects ML
headers, a "reply to list" button. It's than as intuitive as it can get.

But some widely used MUAs don't do this out of the box and next to no
one blames the MUAs for this but try to push their user interface
problem somewhere else (as in "the ML manager must work around my
problem and support exactly my use case - I don't care about all others").

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: Mailing list address harvested for spamming

[Bernd Petrovitsch]

On 02/12/2018 03:05, Michael A. Peters wrote:
[...]
> But - I would wager that over 95% of the time when someone hits the
> reply button on a list post, their intent is to reply to the list.

Even if it's 99%: What is the lesser risk if someone get's it wrong?

Apart from the situation that people send mails over the mailing list
with "for X.Y." in the subject and no one knows how private that should
be. Obviously, it's absolutely not private because it goes to - at least
- all folks on the mailing list.

> If netiquette is why that sometimes fails, then netiquette does not
> match common usage and is the problem.
The netiquette is more than just a piece of "documentation of most of
the people think how it should work".

Please bring serious an factual problems with the netiquette as such and
not just "with some MUA it's not possible" (because it's possible with
really *every* MUA - with some it's just a little more work than with
others) or "most people ignore it because ...

> I would wager that most people are clueless to how mail headers work,
> not should most people need to.

... they are clueless".

In consequence, the clueless people should define how things should work?

Well, there are better solutions than that IMHO.

It's quite the opposite: People should have a *basic* knowledge of the
tools they use - for email e.g. the To:-header has no technical meaning.

Let's hope that people who do not know how to use a tool - e.g. like a
hammer - doesn't use that tool in the first place 

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: Mailing list address harvested for spamming

[Bernd Petrovitsch]

On 02/12/2018 01:09, Noel Butler wrote:
[...]
> all should go to list.  Its also dumb when list admins dont set reply-to

It's quite the opposite.

> list, the entire point of relying to a list, is, well, to the list) 

Sorry, but that tells us more more about the audience of such lists than
you just intended to.

If I want to answer to the list, I press the "reply-to-list" (or
"reply-to-all") button. Sometimes I really just wants to reply privately.

FWIW such bad behaviour of list-admins is usually called "reply-to
munging" and https://www.unicom.com/pw/reply-to-harmful.html should show
why that is always a bad idea (and that a configuration option is
actually a serious bug in any mailing software).

Every sane MUA has separate "Reply to sender" and "Reply to list"
buttons (or similar user-interface elements) for mails with RFC
2919/2369 headers - either directly or via some addons/plug-ins/extensions.

If your MUA is not sane, change the MUA or edit the addresses by hand -
your choice.

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: Dovecot Oy merger with Open-Xchange AG

[Bernd Petrovitsch]

On Mit, 2015-04-01 at 14:42 +0200, Reindl Harald wrote:
> Am 01.04.2015 um 14:33 schrieb Bernd Petrovitsch:
> > On Mit, 2015-04-01 at 13:07 +0200, Reindl Harald wrote:
> >> Am 01.04.2015 um 13:04 schrieb Bernd Petrovitsch:
> >>> IMHO the larger the corporation is, the less are the chances for
> >>> *long-term* benefits of the OSS/free software (mainly because: usually
> >>> commercial success is driven and defined from marketing to sales[1] sown
> >>> to the techies which are forced into "features" and "delivery dates" to
> >>> achieve some "company defined goal" - and that is usually not "bug
> >>> free", "safe", or the like. Free software/OSS just happens that *at
> >>> least* half of it should come from the "working level" and that is - at
> >>> least - much more - ahemm - "inconvenient" for sales people)
> >
> > FWIW the context were large "old-school" corps (like Novell or Oracle)
> > taking over free software companies.
> >
> >> that is simple not true - if it would be true linux distributions would
> >
> > Define "true Linux distribution".
> 
> who the fuck was talking abiut "true Linux distribution"?

Ooops, sry, misread that ("," could help ).
Actually, the whole area/discussion IMHO too versatile to invalidate (or
validate) anything with just one example - not everything is white or
black ...
One had to look at each situation and the circumstances/conditions/...
(and there is no excuse for companies to fix a bugs paid by their
customers and "forget" to send them upstream - if only to get a
confirmation on the quality).

> >> not include half baken and aplha quality sofwtare again and again in
> >> stable releases because "the market out there"
> >
> > That's everywhere in the commercial world the problem with "delivery vs
> > quality/known problems" and someone's decision to ship or not to ship -
> > based in whatever feels appropriate.
> 
> and in the opensource world too - so shwat

Usually a maintainer has no direct pressure on "shipping"/releasing. And
sometimes one actually ships known bugs if only to motivate the ones who
should fix the bugs and one doesn't want to become hostage of some lazy
contributors;-)

[...]
Kind regards,
Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds

Re: Dovecot Oy merger with Open-Xchange AG

[Bernd Petrovitsch]

On Mit, 2015-04-01 at 13:07 +0200, Reindl Harald wrote:
> Am 01.04.2015 um 13:04 schrieb Bernd Petrovitsch:
> > IMHO the larger the corporation is, the less are the chances for
> > *long-term* benefits of the OSS/free software (mainly because: usually
> > commercial success is driven and defined from marketing to sales[1] sown
> > to the techies which are forced into "features" and "delivery dates" to
> > achieve some "company defined goal" - and that is usually not "bug
> > free", "safe", or the like. Free software/OSS just happens that *at
> > least* half of it should come from the "working level" and that is - at
> > least - much more - ahemm - "inconvenient" for sales people)

FWIW the context were large "old-school" corps (like Novell or Oracle)
taking over free software companies.

> that is simple not true - if it would be true linux distributions would 

Define "true Linux distribution".

> not include half baken and aplha quality sofwtare again and again in 
> stable releases because "the market out there"

That's everywhere in the commercial world the problem with "delivery vs
quality/known problems" and someone's decision to ship or not to ship -
based in whatever feels appropriate.

BTW typical Linux distributions package some else's software and
(almost) everyone knows that (and do not blame the distro for shipping
buggy software - is there actually any bug-free software?;-).

And it depends on
- the package (core package like kernel, gcc, perl, apache-http, ...)
  vs some exotic application (the n+1.th text editor, MUA, ...).
- the bug in question - is that stuff unusable or happens the bug only
  if you do crazy creative stuff on files with 6+GB size or 1000k lines?
And usually distros run bug tracking and (try to) get bugs fixed - in
house or upstream.

> the *possible* long-term benefits are more time to invest because a 
> fixed income

If the free software is the core business, it is not a problem (and
these are not the companies in the discussion).

Kind regards,
BErnd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds

Re: Dovecot Oy merger with Open-Xchange AG

[Bernd Petrovitsch]

On Don, 2015-03-26 at 17:01 +0200, Andreas Kasenides wrote:
> On 26/03/15 13:05, Bernd Petrovitsch wrote:
> > On Mon, 2015-03-23 at 16:08 +0200, Andreas Kasenides wrote:
> >> I am usually emotionally (at least) against of open-source projects
> >> loosing their independence to large corporations. Possibly due to bad
> > OX-AG is a "large corporation"?
> > Did I miss something?
> >
> > Kind regards,
> > Bernd
> 
> I have no idea how large is OX-AG. That is not what I said anyway. At 

Well, at least somewhat implicated IMHO.

> least not what I meant.
;-) Fair enough!

> I was trying to emphasize large or larger commercial entities trying to 
> take advantage of the OSS community.
> Which happened many times in the past.

Yes, there were some not-so-promising "take overs" but there were also
others.

IMHO the larger the corporation is, the less are the chances for
*long-term* benefits of the OSS/free software (mainly because: usually
commercial success is driven and defined from marketing to sales[1] sown
to the techies which are forced into "features" and "delivery dates" to
achieve some "company defined goal" - and that is usually not "bug
free", "safe", or the like. Free software/OSS just happens that *at
least* half of it should come from the "working level" and that is - at
least - much more - ahemm - "inconvenient" for sales people).

Bernd

[1]: Sorry, but some "pre-sales techies" which are not really involved
 in the technical realization afterwards are just an excuse for
 the sales department.
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds

Re: Dovecot Oy merger with Open-Xchange AG

[Bernd Petrovitsch]

On Mon, 2015-03-23 at 16:08 +0200, Andreas Kasenides wrote:
> I am usually emotionally (at least) against of open-source projects 
> loosing their independence to large corporations. Possibly due to bad 

OX-AG is a "large corporation"?
Did I miss something?

Kind regards,
Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds

Re: Request to list owner

[Bernd Petrovitsch]

On Die, 2014-10-14 at 09:28 +0100, Jorge Bastos wrote:
[...]
> Sorry for this.

Than don't write it.

> Is it possible to change the reply-to in mailman to be the list, and not the
> person who replied?

Alas, it is possible but not good:
http://www.unicom.com/pw/reply-to-harmful.html
https://woozle.org/~neale/papers/reply-to-still-harmful.html


> Also the [Dovecot] on the subject would be handy.

That wastes screen space and mail filtering is - in the 21st century -
better done on List-Id and similar headers.

> Just two things to get better.

No, much much worse.

Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds

Re: Dovecot and Postfix - dovecot doesn't create sockets

[Bernd Petrovitsch]

On Fre, 2014-06-13 at 15:53 +0200, Bernd Weber wrote:
> Thank you very much for your advice, but that error of postfx I got from 
> the error-log. Dovecot doesn't complain. It only doesn't create the 
> sockets, I have in the service section of 10-master.conf

There should be more somewhere with "permission denied" or similar
somewhere - the more useful programs log everything possibly strange.

Additionally you could start 'dovecot' under "strace" - e.g. `strace -o
dovecot.strace ...` and look for the socket() sys-calls for an error.

Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds

Re: Dovecot and Postfix - dovecot doesn't create sockets

[Bernd Petrovitsch]

Hi!

On Fre, 2014-06-13 at 11:54 +0200, Bernd Weber wrote:
[...]
> Problem: Sockets /var/spool/postfix/private/auth and 
> /var/spool/postfix/private/dovecot-lmtp are not created
> 
> The only error message I get comes from postfix: no auth (SASL) founhd. 
> Takes np wonder, the s ockets don't exist. Any help is welcome.

Look in the log files for the error message.

Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds

Re: Subject tag [Dovecot] is gone

[Bernd Petrovitsch]

On Die, 2014-06-10 at 11:04 -0400, Chris Young wrote:
> Gmail doesn't let me filter on message headers so I've updated my filter as
> follows

One more reason not to use it;-)

[...]
> On Tue, Jun 10, 2014 at 10:51 AM, Koenraad Lelong <
> dove...@ace-electronics.be> wrote:
[...]
> > Just wanted to ask what happened to "[Dovecot]" when I saw this mail.
> > Could you tell me how to find the List_ID ? I looked at the raw mail, but I
> > didn't find it :
[...]
> > Reply-To: Dovecot Mailing List 

You could use that header (which actually should better be gone because
reply-to munging considered harmful) or some other header field with
"dovecot" somewhere.

FTR: I find
  snip  
List-Id: Dovecot Mailing List 
List-Unsubscribe: <http://dovecot.org/cgi-bin/mailman/options/dovecot>,
 <mailto:dovecot-requ...@dovecot.org?subject=unsubscribe>
List-Archive: <http://dovecot.org/pipermail/dovecot/>
List-Post: <mailto:dovecot@dovecot.org>
List-Help: <mailto:dovecot-requ...@dovecot.org?subject=help>
List-Subscribe: <http://dovecot.org/cgi-bin/mailman/listinfo/dovecot>,
 <mailto:dovecot-requ...@dovecot.org?subject=subscribe>
  snip  
in every mail header (=> RFC-2919).
Is someone filtering headers on your side or the MUA just not displaying
really all of them?

[...]
> > Another thing I'm wondering about is if I should allow text/html parts, =
> > because removing them will also break the DKIM signatures. Or mainly I'd =
> > like to allow only multipart/alternative with text/plain + text/html, =

FWIW text/html is actually overrated and - essentially - superfluous.
Additionally it makes it even easier to fool the average user.

Kind regards,
Bernd
-- 
Bernd Petrovitsch   Email: be...@sysprog.at

Re: [Dovecot] Best way from Mbox to Maildir using 2.17?

[Bernd Petrovitsch]

On Mon, 2013-11-04 at 19:29 +1000, Noel Butler wrote:
[...]
> think in postfix   home_mailbox = Maildir/ will do it, with sendmail its 
> much more tricky and your best sticking with mbox, if exim, NFI - dont 

Or - strategically - you use dovecot's LDA which should know where to
throw the mails in.

For sendmail, read http://platyna.platinum.linux.pl/blog/?p=3:
Basically add somewhere in the middle of the /etc/mail/sendmail.mc
(where the other FEATURE() lines are)
  snip  
FEATURE(local_procmail, `/usr/libexec/dovecot/deliver', `deliver -d $u', 
`SPhnu9')dnl
MODIFY_MAILER_FLAGS(`LOCAL', `-f')dnl
  snip  
and add the end, we do not need the procmail-mailer (as above uses/modifies the 
local mailer)
  snip  
dnl MAILER(procmail)dnl
  snip  

Caveat emptor: It's Fedora/RedHat-world over here and installation from
RPMs. So check the paths;-)

Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Dovecot] secure email server

[Bernd Petrovitsch]

On Mit, 2013-10-23 at 15:21 +0200, Frerich Raabe wrote:
> On 2013-10-23 13:21, Reindl Harald wrote:
> > Am 23.10.2013 13:16, schrieb BONNET, Frank:
> >> my first question is : does postfix and dovecot are able to use an
> >> encrypted filesystem such as Encfs?
> >
> > dovecot and postfix are userland-applications
> > it's not their job to bother about a filesystem
> > this is a kernel-task
> 
> Not all userland applications work equally well with all filesystems
> (consider programs which work poorly with NFS because they are built
> around the assumption that certain syscalls are fast).

That assumption is somewhat optimistic and - thus - these applications
are obviously buggy.

Since Dovecot works on NFS, it should work with almost all filesystems
and (relatively) slow ones too.
And MTAs (like postfix) are also build for (and used in) large systems
so they should better work on NFS and slow I/O too.

Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Dovecot] Temporary Failure that's Permanent!

[Bernd Petrovitsch]

On Mit, 2011-10-26 at 21:51 -0500, Stan Hoeppner wrote:
> On 10/26/2011 8:48 AM, Bernd Petrovitsch wrote:
> > On Mit, 2011-10-26 at 02:33 -0500, Stan Hoeppner wrote:
> >> On 10/25/2011 2:34 PM, Charles Marcus wrote:
> > []
> >>> A word of advice... you need to take a breath, and START OVER.
[]
> > Dovecot works fine on my CentOS-5.* and -6.
> 
> Yes, because you know what you're doing.

Every root/sysadmin/administrator is supposed to know what s/he is doing
- even if one runs Ubuntu;-)

[]
> >> And don't roll-your-own-Dovecot from source.

BTW compiling dovecot is the usual `configure; make; make install' IIRC.

For the configuration: if it doesn't work out of the box, you have to
dive into it - even with .rpm/.deb based installs.
And if it works out of the box, it may have a too "open" default
configuration. SCNR 

[]
> > And I used it self-compiled (because there were at times no current
> > packages) and nowadays an RPM from some repo. 
> > Granted with sendmail as MTA but that shouldn't make a big difference.
[...]
> The OP is having trouble with a roll-your-own combo Dovecot and Postfix
> install.  He went this route because the CentOS 5.x packages are old as
> dirt.  Now he's having severe problems getting the RYO stuff working

Yes, because CentOS-5.* is old as dirt as it is basically an extremely
stable enterprise distribution.

> properly.
[...]
> If he has the option of using a distro with far more current packages,
> it would be much easier for him to get up and running.  Thus my

Does he has that option?
Running an old-and-stable distribution may have other reasons than "too
lazy to upgrade".

> suggestion to give Debian a try.  Any distro he's comfortable with and
> has access to, that has relatively up to date Dovecot and Postfix
> versions, would be just as suitable.

Debian/stable is (or at least was) usually similar old as
SuSE-enterprise and RHEL/CentOS. 

> The bulk of his problems stem from issues revolving around installing

If you know that exactly where his problems are, perhaps you should help
him to solve it and just tell him to start somewhere else from scratch.

> from source.  Moving to recent distro packages will very likely solve
> most of his problems.

The most simple usual RHEL/CentOS (and Debian/Stale BTW while we're at
it) solution is to try rebuilt the src.rpm (or src.deb, respectively)
from the current (or a newer) Fedora.
That might or not work without problems (like dependencies on quite
newer version of some libraries) but the try is a matter on an hour or
so.

Kind regards,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Dovecot] Temporary Failure that's Permanent!

[Bernd Petrovitsch]

On Mit, 2011-10-26 at 02:33 -0500, Stan Hoeppner wrote:
> On 10/25/2011 2:34 PM, Charles Marcus wrote:
[]
> > A word of advice... you need to take a breath, and START OVER.
> 
> Yep.  Start by ditching that old as dirt POS distro known as CentOS.

Dovecot works fine on my CentOS-5.* and -6.

> And don't roll-your-own-Dovecot from source.
[]

And I used it self-compiled (because there were at times no current
packages) and nowadays an RPM from some repo. 
Granted with sendmail as MTA but that shouldn't make a big difference.

    Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Dovecot] Maildir over NFS

[Bernd Petrovitsch]

On Mon, 2010-08-09 at 08:02 -0700, Seth Mattinen wrote:
> On 8/9/10 5:31 AM, Bernd Petrovitsch wrote:
> > On Mon, 2010-08-09 at 12:18 +0200, Edgar Fuß wrote:
> >>> The NFS server sits in user space.
> >> Oops? I don't know what Linux does, but with BSD, it has always been 
> >> in-kernel.
> > 
> > Historically there was a user-space NFS-daemon (and can very probably be
> > found via Google today).
> > Actually there are stories about people using it because if you export
> > filesystems via a user-space NFS daemon, you can change the mounting
> > below without affecting the clients for NFS-v3.
> > 
> > But the kernel has a NFS-server since years and all (somewhat common)
> > distributions use it per default.
> 
> Debian still gives you a choice with packages nfs-user-server and
> nfs-kernel-server.

Ah, I wasn't aware of that. Thanks for adding that.

Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Dovecot] Maildir over NFS

[Bernd Petrovitsch]

On Mon, 2010-08-09 at 12:18 +0200, Edgar Fuß wrote:
> > The NFS server sits in user space.
> Oops? I don't know what Linux does, but with BSD, it has always been 
> in-kernel.

Historically there was a user-space NFS-daemon (and can very probably be
found via Google today).
Actually there are stories about people using it because if you export
filesystems via a user-space NFS daemon, you can change the mounting
below without affecting the clients for NFS-v3.

But the kernel has a NFS-server since years and all (somewhat common)
distributions use it per default.

    Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Dovecot] Duplicate Elimination

[Bernd Petrovitsch]

On Mit, 2010-02-24 at 16:51 +0200, Timo Sirainen wrote:
[...]
>  (I hate the whole concept of dropping incoming messages as duplicates
> based on Message-ID. I would definitely want it disabled for my own
> mails, for example that would mean I couldn't filter messages to
> mailing lists based on List-ID: header, because the first mail usually
> comes directly from the other user, and then the second mail with the
> List-ID: would get dropped.)
Aren't those usually two separate mails with different message-ids as
one comes directly by the sender and the other generated by the
mailinglist manager?

    Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Dovecot] Best inode_ratio for maildir++ on ext4

[Bernd Petrovitsch]

Hi!

On Fre, 2010-02-19 at 17:18 -0600, Rodolfo Gonzalez wrote:
[...]
> This might be a silly question: which would be
Not at all IMHO.

> the best inode ratio for a 5 Tb filesystem dedicated to Maildir++
> storage? I use ubuntu server, which has a preconfigured setting for
> mkfs.ext4 called "news" with inode_ratio = 4096, and after formating the
> fs with that setting and then with the defautl setting I see this
> difference of space (wasted space, but more inodes):
> 
> 4328633696 free 1K-blocks with mkfs's "-T news" switch = 1219493877 free
> inodes
> 4557288800 free 1K-blocks with default mkfs settings = 304873461 free inodes
> 
> I'll be storing e-mail messages for around 20,000 accounts on that 
> partition (average 512 Mb per account). Would you consider worth the 
> waste of about 200 Gb of the filesystem space in exchange of more inodes?
That depends entirely if 512MB mail per account a few large ones or a
lot of small ones (assuming that the future behaviour is similar to the
past).
So perhaps it helps to count the files (and directories) on that file
system as each of them actually uses an i-node.

BTW you can set other values than "default" and "news", namely the
number directly.

Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Re: [Dovecot] dovecot: pipe() failed: Too many open files

[Bernd Petrovitsch]

On Fre, 2009-12-18 at 18:32 -0500, Charles Marcus wrote:
> On 12/18/2009, JW (j...@mailsw.com) wrote:
> > I'm sorry, I forgot to specify that I was using Debian Linux:
> 
> You also forgot the bare neceesities, like dovecot version, dovecot -n
> output and log entries exhibiting the problem.
And for the current case looking into /proc/$(pidof dovecot)/fd should
show all open fds (and $(ls -1 /proc/$(pidof dovecot)/fd | wc -l) should
be somewhat near the limit).

> I'm actually amazed at how many people post on support lists and say
> 'Help! Its not working!! What did I do wrong?!' - do they really expect
> meaningful help?
> 
> Even more amazing, on this list Timo can often divine the answer anyway...
He has probably am extremely good crystal ball;-)

Bernd
-- 
mobil: +43 664 4416156  http://bernd.petrovitsch.priv.at/
Linux Software Entwicklung, Beratung und Dienstleistungen

Re: [Dovecot] [OT] DRBD

[Bernd Petrovitsch]

On Die, 2009-11-24 at 13:44 -0600, Eric Jon Rostetter wrote:
[...] 
> I'm doing dovecot off DRBD 8.3, RHCS, GFS, active-active...  Why would
> you recommend DRBD 7 instead of 8?
Because I thought 7 is the newest stable and didn't realized that it is
(apparently) 8.
Thanks for pointing that out!

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

Re: [Dovecot] [OT] DRBD

[Bernd Petrovitsch]

On Mon, 2009-11-23 at 15:25 -0600, Rodolfo Gonzalez Gonzalez wrote:
[...]
> has someone worked with DRBD (http://www.drbd.org) for HA of mail 
> storage? if so, does it have stability issues? comments and experiences 
> are thanked :)
(Now) 25K mailboxes (with ~92GB data) on DRBD-6 (now old - the thing was
built in early 2006) with ext{3,4} on it. As long as heartbeat/
pacemaker/openais/whatever assures that it is mounted on at most one
host, no problems whatsoever with the filesystem as such.
We don't run dovecot though (see the year above) but it shouldn't make
any difference.
Nowadays, DRBD-7+GFS or OCFS2 (and dovecot of course;-) are very
probably worth exploring for new clusters - see other mails.

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

Re: [Dovecot] Users with large (4GB) inboxes crippling dovecot

[Bernd Petrovitsch]

On Thu, 2009-05-28 at 21:28 -0500, Kyle Wheeler wrote:
> On Friday, May 29 at 09:46 AM, quoth Curtis Maloney:
> > This is certainly one advantage dbox and maildir have -- not being 
> > limited to the FS file size limit per folder.
> 
> That's not *entirely* accurate. Certainly no single message can exceed 
> the 2GB limit even with maildir, and the other issue that begins to 
> come up is the impact/effect of large numbers of files. Depending on 
> the filesystem (I'm assuming ext2?), there's probably a hard limit on 

FC4 had ext3 (unless my memory is totally mistaken).

> the number of files per directory, and almost certainly there's a big 

Subdirectories, yes (because the link count in the inode is of quite
finite size).
But there never was TTBOMK a limit on the number of files (!=
Directories) in ext2 (except the trivial one: The directory is as large
as the largest file. But that applies probably to all filesystems -
though more recent ones allow for much larger files).
Let alone ext3.

> performance penalty for that many files. To get good performance with 
> Maildir and really large folders, you need a filesystem that can 
> handle large numbersof files. Ext3 has directory hashing, ReiserFS is 

Make sure you have the "dir_index" option set on that filesystem (which
is probably set per default anyways these days. Otherwise you can change
it on the fly with `tune2fs`).
The back of my head suggests that one has to recreate the directory
after changing that option (read: `mkdir new; mv old/* new; rmdir old;
mv new old`. Solving the "command line too long" problem is left to the
reader;-).

> good... I believe XFS and several others have tackled the problem as 
> well (I don't know about FFS).
> 
> That said... eGADS - a real life FC4 in the wild?!?! According to 
> fedoraproject.org:
> 
> For 20030101-20050607 there are a potential 863 CVE named
> vulnerabilities that could have affected FC4 packages. 759 (88%)
> of those are fixed because FC4 includes an upstream version that
> includes a fix, 10 (1%) are still outstanding, and 94 (11%) are
> fixed with a backported patch.
> 
> That would make me a little nervous that's just the issues over 
> the course of two years, ending in 2005 (FOUR years ago).

I don't know what/how others do but many servers are not really "in the
wild" but behind more recent firewalls and/or loadbalancers and/or
similar equipment (like running database servers behind webservers).

And "running FC4" doesn't mean that that certain/some/several/many
packages aren't replaced by more recent ones - for whatever reason
(security, performance, newer version, newer drivers in the
kernel, ...).

For a "pristine FC4 with lots of services directly at the Internet": I
totally agree with you.

Apart from the basic question if one shouldn't better run a more
conservative distribution (like RHEL) in the first place where the
support cycle is much longer.

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services