Re: fyi: please change /var/run to /run in debian buster repository

[Michael Orlitzky]

On 12/12/20 10:07 AM, Michael wrote:
> 
> in the file
>  /lib/systemd/system/dovecot.service
> 
> the line
>  PIDFile=/var/run/dovecot/master.pid
> 
> to
>  PIDFile=/run/dovecot/master.pid
> 

Not that it matters for systemd, but in general, both /var/run and /run
should be replaced by @runstatedir@ which can then be replaced at
build-time by the appropriate value from ./configure --runstatedir.

That allows a single file to work on both Linux and BSD.

The runstatedir support is part of the official autoconf-2.70 release.

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

[Michael Orlitzky]

On Thu, 2021-07-29 at 14:33 +0300, Mart Pirita wrote:
> Hi,
> 
> 
> This is very bad news.
> 
> I don't think that disto is old, if I can compile almost every
> software with it.
> 
> So at the moment I have two choices, newer upgrade Dovecot or
> rollback the buffer_t changes and use latest version?
> 
> 

If you're willing to build dovecot from source to obtain a newer
version than CentOS provides, you could always do the same thing with
GCC or clang.

Dovecot should respect things like CC=/usr/local/bin/gcc-11

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

[Michael Orlitzky]

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
include headers from a non-default directory.

Re: spool move/rename question

[Michael Orlitzky]

On Sun, 2023-10-08 at 11:27 -0400, Dave McGuire wrote:
>We have an existing user with a lot of mail that we need to move from 
> one domain to another.  Our mail system is database-backed so changing 
> the account is trivial, but can I just move the  directory from 
> the structure above from one  directory to another and expect 
> everything to be ok?  Or is there a better approach? (of course I'll do 
> a backup first)
> 

Moving the directory works fine.

The database part can be trickier than it seems at first. Don't forget
to update the aliases both to and from the renamed user. You might also
need to update the databases for any webmail or caldav/carddav
applications you run. And if you're using mysql, I haven't checked in a
few years, but it didn't used to enforce foreign key constraints or
support cascading updates, so beware that updating one table may not
automatically update dependent tables.

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Avoiding POODLE vulnerability

[Michael Orlitzky]

On Sat, 2023-11-18 at 16:54 -0500, Steve Litt wrote:
> 
> I forgot to say: I'm using Dovecot 2.3.21 on an up to date 64 bit
> x86_64 Void Linux computer using runit for its init system. I populate
> Dovecot's Maildir via fetchmail and procmail.
> 

You probably don't have to do anything. SSLv2 and SSLv3 have been
disabled by default in OpenSSL for a while, and my dovecot default is,

  # doveconf -d | grep ssl_min_protocol
  ssl_min_protocol = TLSv1.2

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Avoiding POODLE vulnerability

[Michael Orlitzky]

On Sun, 2023-11-19 at 15:33 -0500, Steve Litt wrote:
> 
> Thanks Bernardo,
> 
> I use Void Linux, not Debian. Is there a command that tells me the
> defaults?
> 

The one I typed :)

The doveconf command has a few flags that control what settings are
displayed, and "-d" tells it to show the defaults as opposed to what is
currently in use.

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Avoiding POODLE vulnerability

[Michael Orlitzky]

On Sun, 2023-11-19 at 18:28 -0500, Steve Litt wrote:
> 
> doveconf -d shows that I have no such config key as ssl_protocols, my
> ssl_min_protocol is TLSv1.2, and the default ssl_cipher_list is the
> following huge string:
> 
> ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH
> 
> Is the preceding the safest and most bug free, or should I modify it in
> dovecot.conf?
> 

That's the dovecot default and it's reasonably safe. If you're the only
user, you can play around with it and watch the logs to see if it
changes the cipher that your mail client negotiates... but otherwise
you're more likely to create obscure problems than you are to improve
anything.

The string above is intended to enable all ciphers and then blacklist
the weak ones. A few are excluded by name, but most are excluded via
the LOW and EXPORT groups. (Newer versions of OpenSSL once again do
this for you; man openssl-ciphers tells me that LOW, EXPORT, kDHd, and
DES have all been removed as of openssl-1.1.0.)

You could try to improve this by excluding (say) the MEDIUM group, but
you risk breaking clients. The list above ends with @STRENGTH to prefer
stronger ciphers. That means that if you have any clients connecting
with a MEDIUM strength cipher, it's because they
can't use anything better -- disabling MEDIUM will cause problems.

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: IP drop list

[Michael Orlitzky]

On 03/03/2015 11:03 PM, Earl Killian wrote:
> On 2015/3/2 10:03, Reindl Harald wrote:
>>
>> that is all nice
>>
>> but the main benefit of RBL's is always ignored:
>>
>> * centralized
>> * no log parsing at all
>> * honeypot data are "delivered" to any host
>> * it's cheap
>> * it's easy to maintain
>> * it don't need any root privileges anywhere
>>
>> we have a small honeypot network with a couple of ipranges detecting
>> mass port-scans and so on and this data are available *everywhere*
>>
>> so if some IP hits there it takes 60 seconds and any service
>> supportings DNS blacklists can block them *even before* the bot hits
>> the real mailserver at all
>>
> I would like to reiterate Reindl Harald's point above, since subsequent
> discussion has gotten away from it. If Dovecot had DNS RBL support
> similar to Postfix, I think quite a few people would use it, and thereby
> defeat the scanners far more effectively than any other method. It is
> good that other people are suggesting things that will work today, but
> in terms of what new feature would be the best solution, I can't think
> of one better than a DNS RBL.

Please add this support to iptables instead of Dovecot. It's a waste of
effort to code it into every application that listens on the network.

Combined with "--ctstate NEW" and a chain for IMAP packets, it would be
no less efficient.

Re: IP drop list

[Michael Orlitzky]

On 03/04/2015 06:12 PM, Jochen Bern wrote:
> On 03/04/2015 09:45 PM, Dave McGuire wrote:
>> On 03/04/2015 03:37 PM, Oliver Welter wrote:
>>> Am 04.03.2015 um 21:03 schrieb Dave McGuire: 
>>>> Am 04.03.2015 um 20:12 schrieb Michael Orlitzky: 
>>>>> Please add [DNSBL] support to iptables instead of Dovecot. It's a waste of
>>>>> effort to code it into every application that listens on the network.
> 
> (FWIW, I agree that DNSBL hooks have no business being in kernel space.
> A standard *userland* DNSBL client communicating with iptables and
> similar by means of libnetfilter_queue would sound quite promising,
> however ...)
> 

This is what I had in mind. Here's a proof of concept. First, the
iptables rule:

  iptables -A tcp_packets -p tcp --dport 443 -j NFQUEUE --queue-num 1

(the details aren't important, just send something to NFQUEUE #1).

Then create the queue as root, and drop privileges. After that you can
make accept/drop decisions in userspace. This took maybe 15 minutes
using NetfilterQueue from pypi. It would be easy to replace the

  if ipp.src == badguy

test with a real RBL lookup. But then you'd need to make the RBL list
configurable, and implement a scoring system, and document it, etc.
(i.e. all the /actual/ work).

--


import os, pwd, grp
from netfilterqueue import NetfilterQueue
from scapy.all import IP


def drop_privileges(uid_name='dovecot', gid_name='dovecot'):
"""
Drop user/group privileges from root/root to the given ones.
"""
if os.getuid() != 0:
# We're not root *shrug*.
return

# Get the uid/gid from the name
running_uid = pwd.getpwnam(uid_name).pw_uid
running_gid = grp.getgrnam(gid_name).gr_gid

# Remove group privileges
os.setgroups([])

# Try setting the new uid/gid
os.setgid(running_gid)
os.setuid(running_uid)

# Ensure a very conservative umask
old_umask = os.umask(077)


def callback(packet):
"""
Callback function registered through netfilter. Will be called on
every packet passed to the netfilter queue.
"""
badguy = "127.0.0.1"
ipp = IP(packet.get_payload())

if ipp.src == badguy:
print("Dropping packet from %s..." % badguy)
packet.drop()
else:
packet.accept()


nfqueue = NetfilterQueue()
nfqueue.bind(1, callback)

drop_privileges()

try:
nfqueue.run()
except KeyboardInterrupt:
print("Bailing...")

Re: more info about deleting users

[Michael Orlitzky]

On 05/02/2016 03:19 AM, Steffen Kaiser wrote:
> On Mon, 2 May 2016, Tom Sommer wrote:
>> On 2016-04-29 16:25, Matteo Gaito Test Account wrote:
> 
> 
> In fact, I would like to have:
> 
> + full user backup
> + full user removal
> + restore of backup'ed user
> 
> incl. all data, Dovecot creates / maintains by itself, such as Quota, 
> ACLs (of deleted user to other mailboxes), messages and all settings of 
> mailboxes, indexes etc.pp.
> 

You also need to delete any aliases that are associated with that user
in your MTA. And any contacts associated with that address in your
webmail/CardDAV system. And any calendars associated with it in your
CalDAV system. And so on.

Moreover, unless you plan to give root CLI access to your support
people, there needs to be a way to figure out who was removed from SQL
and then perform the necessary cleanup (as root) later on.

I solved this for my own exact use case with mailshears:

  http://michael.orlitzky.com/code/mailshears.php

If you use Dovecot with the PostfixAdmin schema in PostgreSQL, and your
filesystem layout is /, then it will work for you
out-of-the-box. It also supports Roundcube, AgenDAV, and DAViCal.

Any user accounts for Dovecot, Postfix, AgenDAV, DAViCal, or Roundcube
can be,

  * Pruned (cleaned up after someone removes them from PostfixAdmin).
  * Removed directly.
  * And even renamed! Yes, this works:

# mailshears mv mich...@orlitzky.com m...@orlitzky.com

There are examples of everything in the man page.

Like I said, right now it's tailored exactly for my mail system. But,
everything is well-designed and implemented by plugins. If you want to
support LDAP or anything else, it can probably be done with a plugin.

I would also happily accept patches for MySQL support, or to make the
filesystem layout configurable, or anything like that.

Re: [Dovecot] BestPractice to migrate imap mailbox from one machine to another

[Michael Orlitzky]

On 09/09/11 09:34, Tobias Hachmer wrote:
> On Fri, 09 Sep 2011 15:22:54 +0200, Robert Schetterer wrote:
>> Am 09.09.2011 15:14, schrieb Tobias Hachmer:
>>> What is the best way to copy the existing mailboxes from the older
>>> machine running dovecot v1.2.15 to the new naked machine?
>>
>> i used imapsync in a bash script
>> http://ks.lamiral.info/imapsync/
>> at a massive migration
> 
> ok, but this tool is not free of charge.
> Are there any known problems just copying the mailboxes with scp or 
> rsync?
> 

https://fedorahosted.org/released/imapsync/

Re: [Dovecot] Storing passwords encrypted... bcrypt?

[Michael Orlitzky]

On 01/03/2012 08:25 PM, Charles Marcus wrote:


What I'm worried about is the worst case scenario of someone getting
ahold of the entire user database of *stored* passwords, where they can
then take their time and brute force them at their leisure, on *their*
*own* systems, without having to hammer my server over smtp/imap and
without the automated limit of *my* fail2ban getting in their way.


To prevent rainbow table attacks, salt your passwords. You can make them 
a little bit more difficult in plenty of ways, but salt is the /solution/.




As for people writing their passwords down... our policy is that it is a
potentially *firable* *offense* (never even encountered one case of
anyone posting their password, and I'm on these systems off and on all
the time) if they do post these anywhere that is not under lock and key.
Also, I always set up their email clients for them (on their
workstations and on their phones - and of course tell it to remember the
password, so they basically never have to enter it.


You realize they're just walking around with a $400 post-it note with 
the password written on it, right?

Re: [Dovecot] Storing passwords encrypted... bcrypt?

[Michael Orlitzky]

On 01/05/12 06:26, Charles Marcus wrote:
> 
>> To prevent rainbow table attacks, salt your passwords. You can make them
>> a little bit more difficult in plenty of ways, but salt is the
>> /solution/.
> 
> Go read that link (you obviously didn't yet, because he claims that
> salting passwords is next to *useless*...
>

He doesn't claim that, but he's a crackpot anyway.

Use a slow algorithm (others already mentioned bcrypt) to prevent
brute-force search, and use salt to prevent pre-computed lookups. Anyone
who tells you otherwise can probably be ignored. Extraordinary claims
require extraordinary evidence.



>> You realize they're just walking around with a $400 post-it note with
>> the password written on it, right?
> 
> Nope, you are wrong - as I have patiently explained before. They do not
> *need* to write their password down.
> 

They have them written down on their phones. If someone gets a hold of
the phone, he can just read the password off of it.

Re: [Dovecot] Storing passwords encrypted... bcrypt?

[Michael Orlitzky]

On 01/04/12 21:06, Patrick Domack wrote:
> 
> But still, the results are all the same, if they get the hash, it can be
> broken, given time. Using more cpu expensive methods make it take longer
> (like adding salt, more complex hash). But the end result is they will
> have it if they want it.
> 

Unless someone breaks either math or the hash algorithm, this is false.
My password will be of little use to you in 10^20 years.

Re: [Dovecot] Storing passwords encrypted... bcrypt?

[Michael Orlitzky]

On 01/05/12 10:28, Michael Orlitzky wrote:
>>
>> Nope, you are wrong - as I have patiently explained before. They do not
>> *need* to write their password down.
>>
> 
> They have them written down on their phones. If someone gets a hold of
> the phone, he can just read the password off of it.

I should point out, I don't think this is a bad thing!

Re: [Dovecot] Storing passwords encrypted... bcrypt?

[Michael Orlitzky]

On 01/05/12 11:14, Charles Marcus wrote:
> 
> Ummm... yes, he does... from tfa:
> 
> "Salts Will Not Help You
> 
> It’s important to note that salts are useless for preventing dictionary
> attacks or brute force attacks. You can use huge salts or many salts or
> hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t
> affect how fast an attacker can try a candidate password, given the hash
> and the salt from your database.
> 
> Salt or no, if you’re using a general-purpose hash function designed for
> speed you’re well and truly effed."

Ugh, sorry. I went to the link that someone else quoted:

  https://www.grc.com/haystack.htm

The article you posted is correct. Salt will not prevent brute-force
search, but it isn't meant to. Salt is meant to prevent the attacker
from using precomputed tables of hashed passwords, called rainbow tables.

To prevent brute-force search, you use a better algorithm, like the
author says.


>> but he's a crackpot anyway.

Gibson *is* a renowned crackpot.


> Why? I asked because I'm genuinely unsure (don't know enough about the
> innards of the different encryption methods), and that's why I asked.
> Simply saying he's a crackpot means nothing.
> 
> Also...
> 
>> Use a slow algorithm (others already mentioned bcrypt)to prevent
>> brute-force search,
> 
> Actually, that (bcrypt) is precisely what *the author of the article*
> (the one who you are saying is a crackpot) is suggesting to use - I
> guess you didn't even bother to read it or else you'd know that, so why
> bother commenting?

Again, sorry, I don't always know how to work my email client.


> 
> I don't see it as an extraordinary claim, and anyone who goes around
> claiming someone else is a crackpot without evidence to support the
> claim is just yammering.
> 

Your article is fine, but you should always be skeptical because for
every article like the one you posted, there are 100 like Gibson's.


> 
>  No, they don't, your claim is baseless and without merit.
> 
> Most people have never even known what their password *is*, much less
> written it down, because as I said (more than once), *I* set up their
> email clients (workstations, home computers and phones) *for them*.
> 

The password is on the phone, in plain text. If I have the phone, I can
read it as easily as if it was written in sharpie.

Re: [Dovecot] imap-login process_limit reached

[Michael Orlitzky]

First of all, feature request:

  doveconf -d
show the default value of all settings


On 01/16/12 17:41, Don Buchholz wrote:
> 
> The 'doveconf -n' output is attached.  I have not set any
> "process_limit" values, and I don't think I'm getting anywhere close to
> the 1024 default, so I'm pretty confused as to what might be wrong.
> 
> Any suggestions on what to do next are appreciated.


What makes you think 1024 is the default? We had to increase it. It
shows up in doveconf -n output, so I don't think that's the default.

# doveconf -n | grep limit
default_process_limit = 1024

Re: [Dovecot] imap-login process_limit reached

[Michael Orlitzky]

On 01/17/12 09:31, Duane Hill wrote:
> On Tuesday, January 17, 2012 at 14:23:47 UTC, mich...@orlitzky.com 
> confabulated:
> 
>> First of all, feature request:
> 
>>   doveconf -d
>> show the default value of all settings
> 
> You mean like doveconf(1) ?
> 
> OPTIONS
>-a Show all settings with their currently configured values.
> 

Using -a shows you all settings, as they're running in your
installation. That's the defaults, except where they're overwritten by
your config.

I was asking for the defaults regardless of what's in my config file, so
that I don't have to deduce them from the combined doveconf output & my
config file.

Re: [Dovecot] imap-login process_limit reached

[Michael Orlitzky]

On 01/17/12 09:58, Michael Orlitzky wrote:
> 
> Using -a shows you all settings, as they're running in your
> installation. That's the defaults, except where they're overwritten by
> your config.
> 
> I was asking for the defaults regardless of what's in my config file, so
> that I don't have to deduce them from the combined doveconf output & my
> config file.

In other words, I don't want to have to do this:

  mail2 ~ # touch empty-config.conf
  mail2 ~ # doveconf -a -c empty-config.conf | grep limit | head
  doveconf: Error: ssl enabled, but ssl_cert not set
  doveconf: Error: ssl enabled, but ssl_cert not set
  doveconf: Fatal: Error in configuration file empty-config.conf: ssl
enabled, but ssl_cert not set
  default_client_limit = 1000
  default_process_limit = 100
  default_vsz_limit = 256 M
  recipient_delimiter = +
client_limit = 0
process_limit = 1
vsz_limit = 18446744073709551615 B
client_limit = 1
process_limit = 0
vsz_limit = 18446744073709551615 B

to find out that the default process limit isn't 1000.

Re: [Dovecot] imap-login process_limit reached

[Michael Orlitzky]

On 01/17/12 13:15, Don Buchholz wrote:
>>   
> What makes me think 1024 is the default?
> The documentation:
> -->
> http://wiki2.dovecot.org/Services?highlight=%28process_limit%29#imap.2C_pop3.2C_managesieve
> 

That's only for those three services (imap, pop3, managesieve), not for
imap-login unfortunately. Check here for more info,

  http://wiki2.dovecot.org/LoginProcess

but the good part is,

   Since one login process can handle only one connection, the
   service's process_limit setting limits the number of users that can
   be logging in at the same time (defaults to
   default_process_limit=100).

Re: [Dovecot] imap-login process_limit reached

[Michael Orlitzky]

On 01/17/12 14:02, Don Buchholz wrote:
>>
> But, Michael's right, documentation can be wrong.  So, I dumped the
> entire configuration.  Here are the values found on the running system.
> Both imap and pop3 services have "process_limit = 1024".
>

You probably just posted this while my last message was in-flight, but
just in case, 'imap' and 'imap-login' are different, and have different
process limits.

As the title of the thread suggests, you're out of imap-login processes,
not imap ones.

Re: [Dovecot] imap-login process_limit reached

[Michael Orlitzky]

On 01/17/12 14:48, Don Buchholz wrote:
>>   
> Doh!  Thanks, Michael.  I wasn't looking at the original error message
> closely enough.  I scanned too quickly and saw "service(imap)" and not
> "service(imap-login)".  Now the failure when there are only ~200 (total)
> dovecot processes makes sense (because about half of the processes here
> are dovecot/imap-login).
> 
> ...
> 
> Thanks for your help ... and patience.
> 

No problem, I went through the exact same process when we hit the limit.

[Dovecot] [OT] Outlook identities

[Michael Orlitzky]

Nothing to do with Dovecot, but I figured this is the best place to ask.

Do any of the newer versions of Outlook have proper identities support
like Thunderbird, mutt, Roundcube, i.e. every other mail client on Earth?

We have customers who set up ten different mailboxes for one person
because otherwise Outlook won't Do the Right Thing. Is there some way to
make it behave like the others?

 * When sending new mail, you can choose which address to use.
 * When replying to mail, it sends from the address that the message
   was sent to by default.
 * All mail winds up in one inbox.

Outlook (2003, 2007) does do this if you set up different mail accounts,
but we shouldn't have to do that.

Re: [Dovecot] [OT] Outlook identities

[Michael Orlitzky]

On 04/13/12 02:22, Birta Levente wrote:
>>
>> Outlook (2003, 2007) does do this if you set up different mail accounts,
>> but we shouldn't have to do that.
> 
> Control Panel / E-mail (Mail in win7) / Profiles ...
> 
> I hope this help you 

This is more work than setting up multiple accounts =)

Re: [Dovecot] [OT] Outlook identities

[Michael Orlitzky]

On 04/13/12 02:35, Robert Schetterer wrote:
> 
> you can do it with exchange,
> no wonder outlook isnt a internet mail client in first line
> its the client of exchange, so people should use real internet mail
> clients ( TB etc ), if m$ would more be compatible, the need of exchange
> may more less , but this should not be , as cashmakers should live
> forever *g
> 
> http://www.msexchange.org/tutorials/Sending-As.html
> 
> there are a few tricks to goal with profiles etc,  but i saw nothing
> that was equal to thunderbird identities
> 

Exchange... the cure is worse than the disease! This isn't looking good
-- I guess I'll continue to do what I have been: telling people to
switch off of Outlook if they want their mail client to not suck.

[Dovecot] Crash in settings parser (assertion failed: (src_count == ccount))

[Michael Orlitzky]

Lutz Schildt posted this to the Gentoo bugzilla recently:

  http://bugs.gentoo.org/show_bug.cgi?id=415571

There's a backtrace and conf files attached. I was able to find this
possibly-related post from a while ago:

  http://dovecot.org/list/dovecot/2010-September/052963.html

Re: [Dovecot] Can we know when a user read our email?

[Michael Orlitzky]

On 06/03/12 04:43, Ed W wrote:
> 
> Look, I can argue against the idea easily, personally my objection is 
> mail loops, but the point is that the customer demands it, and at 
> present that prevents me bidding for certain types of business...  
> Basically the customer just wants to repro what they got with Exchange


I for one think the plugin is a good idea.

I think read receipts are dumb, of course. But if the customer won't be
persuaded, I would rather have them give their money to you than to the
guy who thinks they're a great solution.

Plus, it will make Dovecot a little bit better as a side effect.

Re: [Dovecot] Can we know when a user read our email?

[Michael Orlitzky]

On 06/03/12 12:06, Robert Schetterer wrote:
> Am 03.06.2012 16:24, schrieb Michael Orlitzky:
>>
>> I for one think the plugin is a good idea.
> 
> what the hell , should the plugin do and how ?
> there is smtp dsn, nothing more makes sense
> 
> looking to the thread subject , you need to have new internet standard
> called
> 
> "braindump over tcp"
> 
> this doesnt exist on exchange too
> 
> mail is smtp, dovecot is no smtp server
> 

You could trigger on the 'seen' flag, and Dovecot is more than capable
of generating messages, especially to mailboxes under its control (see:
sieve).

But... who cares? The worst possible thing that can happen is that he
writes it and makes his customers happy and you pretend it doesn't exist.

Re: [Dovecot] Can we know when a user read our email?

[Michael Orlitzky]

On 06/03/12 13:26, Reindl Harald wrote:
> 
> and now tell us how you "connect" YOUR sent message over SMTP
> to any seen fleeg of another user?
> 

Dovecot could write directly to their mailbox. Otherwise, it could do
whatever the sieve vacation plugin does.


>> The worst possible thing that can happen is that he
>> writes it and makes his customers happy
> 
> if it is his business make people happy with lies, ok
> my business is make people happy by telling them the truth

I don't think he plans to lie. I think he explained the limitations and
they don't care.

People have different tastes. I wouldn't personally use ~100% of the
things that I fix for other people.

Re: [Dovecot] Dovecot 2.1 stable packages for Debian?

[Michael Orlitzky]

On 06/11/12 07:23, Krzysztof Trybowski wrote:
> Hello all,
> it is strange, but Dovecot 2.x still didn't make it into Debian (not
> even backports). It exists in testing, but that's still a long wait.
> OTOH there are official packages built every day (referenced from the
> download page). This puzzles me: why isn't there a build created from
> each stable, released version of Dovecot, so that users of Debian
> Stable could benefit from the new version, and run it on production
> environment? Could you (I mean — the Dovecot team) provide such
> packages? This wouldn't require any major amount of work, since you
> already have daily builds produced. You would just have to run that
> building system once per each released version and keep it available
> for download.
> 
> The reason for this is relatively simple: I'm about to implement a new
> mail server, and I'd like to keep to Debian Stable while using Dovecot
> 2.x. This will make future updates much easier, as I won't have to
> face 1.2 -> 2.0 migration on a production system.

To wind up in Debian stable, a package has to go through a bunch of
testing, and that takes a long time. So you're never going to have
official packages for new software in Debian stable.

That's kind of the point of stable =)

Re: [Dovecot] POP3 dictionary attacks

[Michael Orlitzky]

Eduardo M KALINOWSKI wrote:

Charles Marcus wrote:

Dictionary attacks are a fact of life these days.

Just install some kind of blocking on your firewall (fail2ban is a good
one), and let it take care of the worst of it..


I wonder what  they want by cracking a POP3 server. Read the user's
mails? It's true POP3 passwords are almost always equal to SMTP ones
(which is useful for spamming), but then why not try to crack the SMTP
server directly?



There may not be anything interesting in the user's inbox initially, but 
there might be after the attacker starts sending password reminders from 
eBay, Paypal, etc.

Re: [Dovecot] folder creation with dots in name

[Michael Orlitzky]

Timo Sirainen wrote:

No idea.

But actually there's also another possibility that doesn't involve using
plugins. You could just not use Maildir++ layout by setting e.g.:

mail_location = maildir:~/Maildir:LAYOUT=fs

On Thu, 2009-02-26 at 22:26 +0100, Marko Weber | Salondigital.de wrote:

Hi Timo,
i use gentoo-linux, and installed dovecot via portage.
how do i compile this donwloaded listescap.c ?


You can emerge Dovecot with "noclean" set so that Portage won't remove 
all of the good stuff when it's done:


# FEATURES="noclean" emerge -v dovecot

Then you should be able to find the sources in e.g.,

/var/tmp/portage/net-mail/dovecot-1.1.7-r1/work/dovecot-1.1.7

Slightly unrelated: is the list of options to mail_location documented 
anywhere? There are a few mentions of LAYOUT=fs and CONTROL=wherever in 
the wiki, but I just checked mailbox-list.c and most of them were new to me.

Re: [Dovecot] Pointers for developing a proper encryption plugin?

[Michael Orlitzky]

On 01/06/2011 06:54 AM, Christian Felsing wrote:
> Am 04.01.2011 07:38, schrieb to...@tuxteam.de:
>> The idea upthread (Jan-Frode) to keep a public key server-side and
>> encrypt messages on arrival seems to me the way to go.
> 
> I would support that idea. Private key should be encrypted with users
> passphrase. If user changes password privet key needs to be decrypted
> with old password and reencrypted with new password.
> 
> Public key never changes, so maildir is never required to be touched, if
> user changes password and server does not need to know users secret to
> receive mail.

This still doesn't work, because the administrator is the one who tells
the system to encrypt messages as they arrive. He can peek at the
messages before they're encrypted with the user's public key.

It's impossible to hide the contents of a plain-text message from the
person who receives it in plain text (the administrator). PGP/GPG is the
only option.

[Dovecot] OT: Trojita v0.2.9 Released

[Michael Orlitzky]

There was some interest in Trojita (an IMAP client) on this list at one
point. It looks like it's been seeing steady development again:

 http://jkt.flaska.net/blog/Trojita_v0_2_9__a_Qt_IMAP_e_mail_client.html

Re: [Dovecot] dovecot.org mirrors?

[Michael Orlitzky]

On 04/30/2011 03:11 PM, /dev/rob0 wrote:
> On Fri, Apr 29, 2011 at 08:10:45PM +0300, Timo Sirainen wrote:
>> The mirroring setup is finished. There's a master server now 
>> handling dovecot.org and a mirror server handling www/hg/wiki. 
>> Would be nice to get another reliable fast mirror server if
>> someone wants to donate one :) Requirements are:
>>
>>  - Apache2 with WSGI
>>  - Mercurial
>>  - Patched moinmoin
>>  - ssh + rsync so I can push changes immediately
> 
> I think I had offered you a mirror and/or DNS slaves in the past. ATM 
> we can't manage the Mercurial and moinmoin, but that might change in 
> the near future.
> 
> I can still offer you two DNS slaves, if you're interested in that, 
> but there are other free/gratis services available which can do that 
> quite well.
> 
>> BTW. Apparently there's still something wrong with dovecot.org's 
>> reverse DNS record. It appears to be ok, but some DNS servers have 
>> cached it wrong. I don't know why. We've complained to the ISP.
> 
> Sounds like the TTL was too long before a change was made.
> 
>> Also dovecot.org is currently sharing IP with some other stuff,
>> but should get its own IP some day.
> 
> dovecot.org.3600IN  A   194.89.34.45
> 45.34.89.194.in-addr.arpa. 86400 IN PTR mkentta.iki.fi.
> mkentta.iki.fi. 86400   IN  A   194.89.34.45
> 
> Looks fine, although the PTR is mkentta.iki.fi. and not dovecot.org. 
> I'd use "mkentta.iki.fi" as the HELO name if sending mail from there, 
> but that shouldn't be much of a problem.

At the moment,

  $ dig -x 194.89.34.45

  ; <<>> DiG 9.7.3 <<>> -x 194.89.34.45
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44132
  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL:0

  ;; QUESTION SECTION:
  ;45.34.89.194.in-addr.arpa.   IN  PTR

  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1)
  ;; WHEN: Sun May  1 00:49:20 2011
  ;; MSG SIZE  rcvd: 43


  $ dig +short 34.89.194.in-addr.arpa ns
  $ dig +short 89.194.in-addr.arpa ns
  ns2-usa.global.sonera.net.
  ns2-fin.global.sonera.fi.
  ns1-fin.global.sonera.fi.
  ns1-swe.global.sonera.se.
  ns.ripe.net.


  $ dig +short @ns2-usa.global.sonera.net -x 194.89.34.45
  mkentta.iki.fi.

  $ dig +short @ns2-fin.global.sonera.fi. -x 194.89.34.45
  mkentta.iki.fi.

  $ dig +short @ns1-fin.global.sonera.fi -x 194.89.34.45
  mkentta.iki.fi.

  $ dig +short @ns1-swe.global.sonera.se. -x 194.89.34.45
  mkentta.iki.fi.

  $ dig +short @ns.ripe.net -x 194.89.34.45


It looks like that last one could be the problem.

Re: [Dovecot] n00b here -- pop email deletion

[Michael Orlitzky]

On 07/10/2011 07:45 PM, Glenn English wrote:
> I'm running Dovecot IMAP and POP3 on Debian. But it look's like it's
> keeping mail in the user's inbox on the server until it's deleted by
> the user. I thought POP servers deleted email as soon as it was
> downloaded, but apparently not, according to dovecot.org.
> 
> Is there something in the Dovecot conf I can do to get rid of all
> this redundant crud?
> 
> I see several conversations on the 'Net about "quotas" that look like
> they might keep stuff around for a few days or weeks, then delete.
> That sounds lovely, but I don't understand them enough to try to make
> it happen.

You can do things on the server to mitigate damage from people who check
the "leave messages on server for eternity" box, but generally, this is
a client preference.

Outlook, off the top of my head, has at least

  * never delete
  * delete messages after N days
  * delete messages after I delete them locally
  * delete immediately

Re: [Dovecot] n00b here -- pop email deletion

[Michael Orlitzky]

On 07/10/2011 07:59 PM, Glenn English wrote:
> 
> On Jul 10, 2011, at 5:52 PM, Michael Orlitzky wrote:
> 
>> You can do things on the server to mitigate damage from people who
>> check the "leave messages on server for eternity" box, but
>> generally, this is a client preference.
> 
> What things can I do on the server? Many of my people use Macs, and
> there's nothing (I can find) in the iMail config to turn off the
> eternity switch.
> 

With POP3, they don't have a "Trash" folder so you're probably stuck
setting a quota[1].

You could also run a cron job or maybe use the expire plugin to get rid
of old messages, but that would likely piss someone off eventually.

And, I guess, if they're leaving *every* message on the server, you
could switch them to IMAP. They can't possibly leave any more stuff on
there, right?


[1] http://wiki2.dovecot.org/Quota

Re: [Dovecot] POP3 vs. IMAP Load/Memory usage in Dovecot 1.0.15

[Michael Orlitzky]

On 07/11/11 15:57, Matthew Macdonald-Wallace wrote:
> 
> LOL. I'm not a fan of Centos but it's what we've got to play with here -
> We'll be running Debian (or possibly even Gentoo if I have my way...) on
> the next load of servers and custom kernels aren't an issue.

Just don't tell anyone:

  http://www.gentoo.org/proj/en/gentoo-alt/prefix/

Re: [Dovecot] 76Gb to 146Gb

[Michael Orlitzky]

On 09/24/2012 01:42 PM, Spyros Tsiolis wrote:
> Hello all,
> 
> I have a DL360 G4 1U server that does a wonderfull job with dovecot horde,
> Xmail and OpenLDAP for a company and serving about 40 acouunts.
> 
> The machine is wonderful. I am very happy with it.
> However, I am running out of disk space.
> It has two times 76Gb Drives in RAID1 (disk mirroring) and the capacity
> has reached 82%. 
> 
> I am starting of getting nervous.
> 
> Does anyone know of a painless way to migrate the entire contents directly
> to another pair of 146Gb SCSI RAID1 disks ?
> 
> I thought of downtime and using clonezilla, but my last experience with it
> was questionable. I remember having problems declaring disk re-sizing
> from the smaller capacity drives to the larger ones.

We've done this on the same hardware. You can pick up these servers for
cheap; just buy an extra one. Take the new machine, throw two big disks
in it, and install Gentoo.

Rsync the important stuff. Make sure all of the services are working on
the new machine.

When you're ready to make the switch, disable external networking on the
current live server. Rsync everything again, and then turn the old
server off. Add its IP address to the new server. Maybe kick your
router's ARP cache to expedite the change. It should only cause a minute
or two of downtime.

Re: [Dovecot] 76Gb to 146Gb

[Michael Orlitzky]

On 09/24/2012 10:59 PM, Michael Orlitzky wrote:
> 
> We've done this on the same hardware. You can pick up these servers for
> cheap; just buy an extra one. Take the new machine, throw two big disks
> in it, and install Gentoo.

I seem to have gone insane, I thought this was on gentoo-user for some
reason. Anyway, it's a fine suggestion =)

Re: [Dovecot] [SOLVED] Installing Dovecot on Gentoo

[Michael Orlitzky]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/13/2013 02:41 PM, Branko Majic wrote:
> 
> Slightly off-topic from my side, but wanted to mention it since
> I've worked with POSIX ACLs a bit.
> 
> Personally, I've had very bad experiences with POSIX ACLs. They can
> act in quite an unintuitive way when you start combining them with 
> different umask's, originating directory/file permissions (in case
> of copying), sticky bits, and chmod's on files/directories where
> you've already set-up the permissions (not to mention that some
> stuff seems to outright ignore it, like mod_php5/php).

Most of the problem is that the utilities don't support it, and the
tooling isn't there to make it easy to fix things when they get messed up.

GNU tar, cp, and mkdir for example claim to support ACLs, but then do
it only half way: if you copy a non-ACL file into a directory with a
default ACL, cp will preserve the group bits -- which are now the ACL
mask -- making your ACLs useless.

I've had very little success getting things fixed; most people just
aren't interested.

I have a standalone utility called apply-default-acl (now in Gentoo)
that can reapply the default ACL on a file or tree, fixing most of
these issues after the fact. I've patched tar, cp, and mkdir to
reapply the default ACL after they're done screwing things up, but for
other utilities, you just have to call `apply-default-acl -r` on the
result.

I wrote some stuff about this problem at [1].

The other half of the problem is that there's no "just do what I want"
command to set ACLs on a hierarchy. For this I've created scripts
called set-ro-perms, set-rw-perms, etc. It's just find, xargs, and
setfacl -- but it makes a world of difference. There is a recursive
mode for apply-default-acl now which can mimic most of them; you just
need to set a default ACL on '.' and run it.


> I've also attempted using it at some point for some LAMP apps I've
> deployed, and ended-up abandoning them in favour of group sticky
> bits on directories (wanted to administer the web app with regular
> account, while still letting the Apache access files using umask
> 0007).
> 
> So, personally, I'd avoid using them.
> 

Same use case here, except we have multiple groups and users who need
differing levels of access, and each website runs as a different
system user. I don't know of any other way to do it.

Eventually, NFSv4 ACLs[2] are supposed to supercede the POSIX ones.
Hopefully, unlike POSIX, the NFS ACLs will get standardized and
actually gain some traction and decent support. At that point it
should be fairly simple to migrate, since there's an "easy" mapping
from POSIX to NFSv4.



[1]
http://michael.orlitzky.com/articles/problems_with_posix_acls_and_common_utilities.php

[2] http://wiki.linux-nfs.org/wiki/index.php/ACLs
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJQ8zJ5AAoJEBxJck0inpOir+MP/1p///gBNmXO3qQVOZabAXDc
iYUMgiZ48WSpg7SKHUus80nKrue1IQdHC69ORTo7QUFw8o2/8CYXQo6v1EaytyDJ
f702Qx7nMnwvdjH5PZQbxVi3qd+L3I+vwmH4omx2g4cFzM4KWNNXcG+tgWALquAc
0xMn8IpODfqV4SqNx1vjHKH35MBuPtyN+0YxGTixlryxQjSjSaSITxFEfRdXvzLT
xL2WQw++XT5yC1UOyET4F/HQ0BG1C5jIB1auxrkLYQo3a4u+fXFjNQ3r67rL6Jus
t9Z3drj48LSHeyc3tRV0MsIiVhgXGTmGyG+XR7DREt9MbMv2SjHbOtP6YsQ7tVpN
54JndK7Rbcm6yaSExBxCC7eCqgXb5AR10J8AijPwnNj2I6CstHMlG4lLqWvj8Bdm
YQBdid3zbnb8r8sbpwe67UUArwMZWzVReZpETYbW4BrBy7CTPaooizP0fOE/mNwn
78vc5L+1I3edQEOtD3DQhUOFKxPFjJh1x4EdDNzd0K5+a1ZgfBxYw/U6q8ItBJ12
leoNzWMvZklJb/U4gGx2fYSwlZM1wxDGfRp0P63YYvNSaEXloGcRuozVInIzpm3g
QOA5I/1ux7WiisQoln74gJGkPPnbZuAOs45xEl0RUjrWJGzgSWpc8I8h5j755COV
w80fwFF4c5SIYXf/luor
=/6b8
-END PGP SIGNATURE-

Re: [Dovecot] Managesieve patch for Dovecot v1.2.10 on Dovecot v1.2.11

[Michael Orlitzky]

On 03/18/10 01:39, Andreas Schulze wrote:

Am 17.03.2010 17:45 schrieb Ivica Glavocic:

Can i use Managesieve patch for Dovecot v1.2.10
on new Dovecot version v1.2.11

at least: it compiles ;-)
I will try these days



http://dovecot.markmail.org/thread/dcwt26hciua55cz4

Re: [Dovecot] SQL Server

[Michael Orlitzky]

On 05/21/10 18:00, Bryan Vyhmeister wrote:

On Fri, May 21, 2010 at 4:10 PM, Jerry  wrote:


If you can access the Microsoft SQL Server from the machine hosting
Dovecot, there should be no problem at all. I have used Microsoft's SQL
sever for for several projects and it is an extremely fast and robust
piece of software.

Perhaps you could post a clearer picture of exactly what you are
attempting to accomplish.


Sorry. I should have been more specific. I want to use SQL Server for
the userdb and password database. I looked through the wiki and did a
number of searches but could not find an answer. If I were to use
sqlite, mysql, or pgsql, these would be listed under driver = in the
dovecot-sql.conf (or whatever you want to name it). How would you go
about using SQL Server? There is no sql-server driver as far as I
know. I have and am currently using dovecot from passwd files and from
sqlite databases so I am pretty familiar with how everything works. I
am just not sure how to go about this for SQL Server. Thank you.

Bryan


You can specify arbitrary .NET DLL functions to be executed from 
triggers in Microsoft SQL Server, and there are .NET libraries to talk 
to Postgres, so just do it the other way around: run Dovecot off of a 
local Postgres install, and feed it data from Microsoft SQL every time 
something changes.


Here's an example assembly.

/* Begin C# */
using System;
using System.Net;

public class StoredProcedures {

  public static void InsertPostgres(string username, string password) {
   /* This part is your job. */
  }

  public static void UpdatePostgres(string username, string password) {
   /* This part is your job. */
  }

  public static void DeletePostgres(string username, string password) {
   /* This part is your job. */
  }

}
/* End C# */

Now,

1. Compile the assembly to a DLL. Call it e.g. PostgresStoredProcedures.

2. Enable CLR code to run within the database:

  EXEC sp_configure 'clr enabled', 1;
  RECONFIGURE;

3. Make your database trustworthy. This is necessary because it will
be accessing external resources.

  ALTER DATABASE  SET TRUSTWORTHY ON

4. Add the assembly to your database. This will fail if you haven't
set TRUSTWORTHY ON in step 3. Note that this should be done *within*
the database, not to SQL server in general (i.e. the master database).

  CREATE Assembly PostgresStoredProcedures
  FROM ''
  WITH PERMISSION_SET = EXTERNAL_ACCESS

5. Create the stored procedures within the database. Their signatures
should match those of the class methods.

  CREATE PROCEDURE InsertPostgres(@username nvarchar(256),
  @password nvarchar(256))
  AS
  EXTERNAL NAME PostgresStoredProcedures.StoredProcedures.InsertPostgres

  CREATE PROCEDURE UpdatePostgres(@username nvarchar(256),
  @password nvarchar(256))
  AS
  EXTERNAL NAME PostgresStoredProcedures.StoredProcedures.UpdatePostgres

  CREATE PROCEDURE DeletePostgres(@username nvarchar(256),
  @password nvarchar(256))
  AS
  EXTERNAL NAME PostgresStoredProcedures.StoredProcedures.DeletePostgres

6. You can now execute the stored procedures from within SQL:

  exec InsertPostgres 'u...@example.com' 'password'


At this point, you just need to define three triggers on your user 
database -- one for each of insert, update, and delete -- that will 
execute those stored procedures. This is left as an exercise (but really 
is trivial once you've made it that far).

Re: [Dovecot] Proxy Access (Manager/Secretary) Best Practices?

[Michael Orlitzky]

On 06/17/2010 12:31 PM, Chris Hobbs wrote:

I've mostly got our dovecot+postfix+SOGo+openldap open source
groupware replacement working the way I want it to; we're replacing
GroupWise in our organization and I'm thrilled to be doing it. I'm
supporting about 1,000 active staff users (and another 6,000 student
accounts).

I've got e-mail and calendar sharing working, and it does what it
says it will do, but it is (go figure) different in concept from
Proxy access under GroupWise. In GroupWise, I can give my secretary
proxy access to my account and she can read all of my folders, see my
calendars, and send e-mail as me. To someone that receives an e-mail
or appointment request from her while she's proxied to me, there's no
distinction at all.

Is there a way to mimic this sort of functionality with the tools
I've chosen? I've figured out that I can add additional 'mail'
attributes to the secretary's record, and those addresses are
available as drop-down choices in the SOGo web interface, but with
the secretary's name and not the manager.

Any advice will be much appreciated.

And many thanks to the developers involved for writing and making
available such amazingly good software. Eliminating the license fees
we've been paying to Novell is allowing me to save a technician that
surely would have been eliminated in budget cuts this year.


Have two passwords, a secretary one and your real one. When you want to 
give your secretary access, change it to the secretary password. To 
revoke, change back.


(I know nothing about SOGo, so this is my brute force suggestion should 
no one provide a more intelligent one.)

Re: [Dovecot] Certificat Outlook 2003

[Michael Orlitzky]

On 08/10/2010 06:43 AM, Richard Gliebe wrote:

On 8/10/10 12:29 PM Ladislav Pašek wrote:

If your clients are in the Active Directory you could put your server
certificate to domain policy.

Lada


Hi,

the clients are not in a AD, only in a smb workgroup.


You can still download the certificate (from, say, your website) and 
install it on each workstation. Just right click the cert file, and I 
think the option is either "Install" or "Import."

Re: [Dovecot] Certificat Outlook 2003

[Michael Orlitzky]

On 08/11/2010 03:30 AM, Richard Gliebe wrote:

On 8/10/10 6:01 PM Michael Orlitzky wrote:


You can still download the certificate (from, say, your website) and
install it on each workstation. Just right click the cert file, and I
think the option is either "Install" or "Import."


Will this also works with *.pem certificates?


Short answer: yes, although you might have to rename the cert file with 
an extension that Windows understands.


Long answer:

The PEM format is really just a container format for keys and some other 
stuff, so you should double-check what's in the PEM file first. Often, 
they will contain,


  * Just a private key
  * Just a public key or certificate
  * Both a private and public key

For example, if your CERTDIR and KEYDIR are the same when you run 
dovecot_mkcert.sh, then both the public and private keys will be stored 
in the same file (e.g. dovecot.pem).


You want to be careful that you don't ship your private key off to the 
clients. The certificate is contained in one of those PEM files; if you 
put it on a Windows box and give it an extension that Windows 
understands, you should be able to import it.


The PEM files are just plain text, and it should be obvious from the 
"BEGIN CERTIFICATE" or "BEGIN RSA PRIVATE KEY" which one you're looking at.

Re: [Dovecot] Forcing users to change passwords

[Michael Orlitzky]

On 08/15/2010 12:58 PM, Marc Perkel wrote:

Suppose I have users with a default password like "change-my-password"
and I want to detect users who haven't changed their password and alert
(nag) them about changing it. How would I do that?



Write a script that checks your user/password database for that 
password, and sends an email to those users.


If your passwords are hashed, you can create a new user with 
"change-my-password" as its password and check the DB to see what that 
hashes to.

Re: [Dovecot] Single instance storage - testing please

[Michael Orlitzky]

On 08/26/2010 04:41 PM, Mike Abbott wrote:

1. What hash algorithm to use?



2. Should I add support for trusting hash uniqueness


Use two hash functions and concatenate the hashes.  While both hash
systems may eventually be hacked it is unlikely that hacking them
will result in a targeted alias.


Just make it possible to change the hash in the future. Have a utility 
that updates all (or a subset) of them.


If e.g. SHA256 is truly broken in the future, the utility can run 
overnight while I fix the million other emergencies that are about to 
exist in the morning.

Re: [Dovecot] Single instance storage - testing please

[Michael Orlitzky]

On 08/26/2010 09:00 PM, Timo Sirainen wrote:

On 27.8.2010, at 1.52, Michael Orlitzky wrote:


On 08/26/2010 04:41 PM, Mike Abbott wrote:

1. What hash algorithm to use?



2. Should I add support for trusting hash uniqueness


Use two hash functions and concatenate the hashes.  While both
hash systems may eventually be hacked it is unlikely that hacking
them will result in a targeted alias.


Just make it possible to change the hash in the future.


I'm thinking about mail_attachment_hash setting where you can
configure it pretty much any way you want.


Have a utility that updates all (or a subset) of them.


That won't be necessary. Once the hash changes, the new files are
created with new hash function and it doesn't matter if the old hash
is broken because you can't generate new files with it anymore
anyway.



Won't files hashed with the old function begin to dupe though?

Re: [Dovecot] Single instance storage - testing please

[Michael Orlitzky]

On 08/26/2010 09:38 PM, Timo Sirainen wrote:

On 27.8.2010, at 2.24, Michael Orlitzky wrote:


Have a utility that updates all (or a subset) of them.


That won't be necessary. Once the hash changes, the new files
are created with new hash function and it doesn't matter if the
old hash is broken because you can't generate new files with it
anymore anyway.



Won't files hashed with the old function begin to dupe though?


You mean new hash would become a duplicate of the old? Well ..

1) It's highly unlikely to happen, especially because with the new
hash function there again shouldn't be a way to create any specific
hash.


Oh, no, that's not what I meant.

I mean, my friend sends me a video of two cats cuddling, and it gets MD5 
hashed and stored somewhere (it's the first instance of that file in my 
SIS). Tomorrow, I read the newspaper from 2005 explaining how MD5 is 
broken, and decide to switch my hash function to MD4 for safety reasons. 
A week later, another friend sends me the same video (it's REALLY cute). 
Doesn't the video get stored again?

Re: [Dovecot] deliver and time

[Michael Orlitzky]

On 10/04/2010 02:19 PM, Rick Romero wrote:
>   Hi All,
> 
> I've been experimenting with deliver on my personal domain, and so far 
> everything has been peachy except for Mail.app.  Mail.app (on multiple 
> devices) is showing what looks to be GMT times, rather than the date 
> header.  Initially I thought it was something I did on my Mac, until I 
> got an Ipad to test with - and never connected it to my Mac - and had 
> the same time issue.
> 
> It seems Mail.app uses the timestamp ('arrived date'?) on the mail file 
> itself (Maildir here) to display the time.
> 
> So.. I have dovecot 1.2.10 installed on top of vpopmail (multiple MXs, 
> delivering to OpenSolaris NFS share via tcp), and it seems that deliver 
> is using the GMT time when writing the Maildir file, and vdelivermail 
> just uses the adjusted time.. Or maybe it just allows the OS to write 
> the timestamp.
> 
> Either way, is this a known issue with deliver - or is there a patch?  I 
> don't recall ever seeing it come up on the list, and I'm not seeing 
> anything in the changelog.

Your mail client doesn't even know that a Maildir file exists. Can you
post the headers of the message, along with the expected/actual results?

(My guess would be that Mail.app thinks you live in Greenwich.)

Re: [Dovecot] SSL / TLS

[Michael Orlitzky]

Timo Sirainen wrote:

On Fri, 2009-06-26 at 23:39 +0400, Proskurin Kirill wrote:

SSL just binds to special port(like 993 in IMAP by default).


No, SSL is a protocol, just like TLS. It doesn't bind to any ports.
http://wiki.dovecot.org/SSL



To illustrate, both SSL and TLS as implemented in Dovecot utilize "SSL 
certificates."


A typical "TLS" session will work as follows:

1  The client connects to the IMAP service on port 143, unencrypted.
2  The server announces that it speaks TLS.
3  The client says "Ok, let's talk encrypted."
4  Magic occurs, and the session becomes encrypted. This step is where
   your "SSL" certificate is used.
5  The rest of the session is encrypted.

/Usually/, when people refer to SSL as opposed to TLS, they mean IMAPS 
or POPS. These differ in that there's no "Hey, I speak TLS" step. It is 
assumed that the conversation will begin according to some secure 
protocol, kind of like when you connect to a web server on port 443.


1  The client connects to IMAPS on port 993, and performs the secure
   handshake. Your "SSL" certificate is used in here somewhere.
2  Once the handshake has completed, the rest of the session is secure.

When implementing IMAPS/POPS you will usually use a different port, 
because if you tried to talk plaintext to the server, it would appear to 
be speaking gibberish (whatever secure protocol is being used).


With TLS enabled on a normal IMAP port, the switch from plaintext to 
encrypted is optional. Although, it's usually a good idea to force TLS, too.


Much of the confusion comes from the fact that you can use either 
protocol, TLSv1 or SSLv3 after the "Hey I speak TLS" step. Likewise, you 
can use TLSv1 with IMAPS or POPS, though it's use will be implied and 
there will be no "Hey, I speak TLS" step. There's really no agreement 
amongst mail clients as to the meaning of "Use SSL" and "Use TLS."


You may find it easiest to concentrate on the one distinction: does the 
session begin encrypted, or does it switch from plaintext to encrypted 
at some point? Once you've answered that, either of the SSLv3 or TLSv1 
protocols can be used, and they will both use your "SSL" certificate.


Ultimately, you may wind up using both, depending on your user base. 
Many versions of Outlook are screwy with regard to one or both of these 
methods.

Re: [Dovecot] SSL / TLS

[Michael Orlitzky]

Carlos Williams wrote:

On Fri, Jun 26, 2009 at 5:46 PM, Michael Orlitzky wrote:

A typical "TLS" session will work as follows:

1  The client connects to the IMAP service on port 143, unencrypted.
2  The server announces that it speaks TLS.
3  The client says "Ok, let's talk encrypted."
4  Magic occurs, and the session becomes encrypted. This step is where
  your "SSL" certificate is used.
5  The rest of the session is encrypted.


Thats a great and informative breakdown. I guess I just don't see a
benefit of using either over another.
It would appear that using SSL where the session is assumed before
established to be encrypted rather
than switching to encrypted just saves time. They both appear to do
the same thing. Obviously from what
I read, TLS is newer than SSL but sometimes thats not always a good
thing. I just don't know in this case.
Do you recommend I do one over the other? I don't really have a
requirement here at all yet so that being
said, I would rather someone who has better understand of this tell me
what they would do for a simple
Postfix / Dovecot install on a Linux server.


The benefit of using TLS via STARTTLS (Hey, I speak TLS...) is that you
can offer both encrypted and plaintext IMAP on the same port. Since you
don't want to offer plaintext IMAP, you're correct that there isn't much
difference between the two.

Your users will most likely determine which method(s) you can use. Start
out with one, and then add the other if anyone has trouble. Both are
perfectly secure as long as you don't allow plaintext authentication
(disable_plaintext_auth = yes) [1].

IMAPS on port 993 has better client support in my experience, but
occasionally, port 993 will be blocked e.g. at universities where the
admins have never heard of it.

Postfix is a different story. You have to support plaintext SMTP if you
want to receive mail. Encryption on port 25 is therefore, at best,
optional. This makes TLS via STARTTLS the obvious choice.

Do your users submit mail to port 25 (SMTP), or 587 (submission)? If the
latter, then the Postfix configuration is particularly simple. The 
configuration below will set a default where TLS is optional for all 
incoming messages. Then, in master.cf, that default is overwritten to 
force TLS on port 587.



main.cf
---
smtpd_tls_security_level = may
smtpd_tls_cert_file = 
smtpd_tls_key_file = 


master.cf
-
submission inet n   -   n   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject


[1] Caveat: When you set disable_plaintext_auth = yes, and a client 
connects on port 143, Dovecot basically says "DON'T SEND YOUR PASSWORD 
IN PLAIN TEXT BECAUSE IT WON'T WORK." There is at least one client -- I 
don't remember which -- that ignores this and sends the password *in 
plain text* anyway. Someone on this list can probably identify the 
client. If any of your users insist on using it, stick with IMAPS on 
port 993.

Re: [Dovecot] ManageSieve for 1.2.0?

[Michael Orlitzky]

Joan wrote:

yes, Mercurial repository has a working status.

Anybody to help on teh following ? :
-> how managesieve works between the "sieve script per virtual user" and 
the main script in the storage directory.


ManageSieve shouldn't be used to modify global scripts, only personal ones.

With older versions of Sieve, once a user creates a personal script (and 
marks it active), the global script will no longer be called. You can 
work around this by 'include'ing the global script in each personal 
script. Here is my active script, which runs the global script followed 
by a personal one:


  require ["include"];
  include :global "spamassassin-header-filter.sieve";
  include :personal "mailing-lists.sieve";

In newer versions of Sieve (newer than v0.1.3 or v0.1.4, I think), you 
can use sieve_before or sieve_after to accomplish the same thing. Check 
the wiki:


  http://wiki.dovecot.org/LDA/Sieve/Dovecot

If I were using sieve_before in my configuration, there would be no need 
to include the global script manually; it would always be executed 
before my active personal script.

Re: [Dovecot] v2.0 configuration parsing

[Michael Orlitzky]

Timo Sirainen wrote:

I'm trying to figure out how exactly v2.0 should be parsing
configuration files. The most annoying part is if it should always just
"use whatever comes first in config" or try some kind of a "use most
specific rule". The "most specific" kind of makes more sense initially,
but then you start wondering how to handle e.g.:

1) User logs in to imap from 192.168.0.1. What is foo's value?

protocol imap {
  remote_ip 192.168.0.0/16 {
foo = foo
  }
}
remote_ip 192.168.0.0/24 {
  foo = bar
}

2) User logs in from 192.168.0.1 to 10.1.2.3. What is foo's value?

local_ip 192.168.0.1 {
  remote_ip 10.1.2.0/24 {
foo = foo
  }
}
remote_ip 10.1.2.3 {
  local_ip 192.168.0.0/24 {
foo = bar
  }
}

Any thoughts?


I think the easiest scheme to keep in my brain would be to evaluate the 
blocks, in order, as if they were branches in code. Fooling around with 
an arbitrary order of evaluation/specificity would be a recipe for 
disaster (see, for example, any CSS engine).


So, something like,

  protocol imap {
remote_ip 192.168.0.0/16 {
  foo = foo
}
  }

would translate to,

  if (protocol == imap) {
if (remote_ip matches 192.168.0.0/16) {
  foo = foo
}
  }

and then later,

  remote_ip 192.168.0.0/24 {
foo = bar
  }

would set the value of 'foo' to 'bar', since it would evaluate in a 
similar fashion, and comes later in the config file.


It's easy to explain, easy to implement, and easy to debug. Ultimately, 
the users are going to have to understand how it works in order to 
configure Dovecot properly. "Put the most general rules first, and then 
override them" is a practice with which most of us are already familiar.

Re: [Dovecot] TLS / SSL mixed w/ plaintext auth and virtual hosting

[Michael Orlitzky]

Nathan M wrote:

Traditionally this server has only accepted plaintext authentications;
however, we want to change that and enable TLS/SSL.  The challenge is
the server has hundreds of IP addresses it binds to to listen on ports
110/143.


It may be 3am, but I'm pretty sure that this is the part of your setup 
that doesn't make sense. Why does your POP/IMAP server need to be 
accessed via so many addresses?

Re: [Dovecot] TLS / SSL mixed w/ plaintext auth and virtual hosting

[Michael Orlitzky]

Nathan M wrote:

On Thu, Aug 27, 2009 at 12:03 AM, Michael Orlitzky wrote:

Nathan M wrote:

Traditionally this server has only accepted plaintext authentications;
however, we want to change that and enable TLS/SSL.  The challenge is
the server has hundreds of IP addresses it binds to to listen on ports
110/143.

It may be 3am, but I'm pretty sure that this is the part of your setup that
doesn't make sense. Why does your POP/IMAP server need to be accessed via so
many addresses?



Because everybody wants to check email at mail.$theirdomain.com.


But that can be a CNAME for mail.$yourdomain.com, which resolves to one 
address.




Also, some users "need" to check email with username only, so the
local_ip variable is used within the dovecot-sql query to lookup some
virtual users by  username only + match the local_ip to a table with
domain+ip lookup.


Ok, you got me. How many users need that ability? Would anyone notice if 
you killed them?


I started writing a long and involved migration plan to work around this 
requirement, but honestly, "wait for v2.0" is probably a better one.

Re: [Dovecot] architecture to handle 1000 messages per second?

[Michael Orlitzky]

Bob Eastbrook wrote:

On Fri, Jan 1, 2010 at 3:07 PM, Thomas Løcke  wrote:


Hi Bob,

Just to make sure I understand you: Some app is sending emails to
ord...@example.com at the rate of 1000 per second, and another app is
fetching email from ord...@example.com to process them?


Hello,

Actually, thousands of customers would send order emails to a system
running postifx.  All orders end up in ord...@example.com.  Then,
another app fetches these emails via Dovecot (POP or IMAP), ideally at
the rate of 1000 per second.

I think it might be difficult to accomplish this via POP since I think
Dovecot would have to lock the account while doing the POP downloads.
This makes it difficult to have more than one app downloading at a
time.

Cheers,
Bob


Don't use POP3 or IMAP; instead deliver the messages to a command. For 
example, GNU Mailman is mailing list software which pipes each incoming 
list message to a Python script. That command can then perform the 
necessary processing.


I don't know what you had in mind, but if the messages can be handled 
independently, it's easy to add new machines. Just duplicate the config 
on another box, and create an MX record for it.



virtual_alias_domains
-
# Each address in example.com must be aliased to a local user.
example.com IGNORED


virtual_alias_maps
-
# The virtual address "ord...@example.com" is mapped to the local user
# of the same name.
ord...@example.com  orders


alias_maps
-
# And then the local user's mail is delivered to a script rather than to
# a mailbox.
orders  "|/path/to/your/script"

Re: [Dovecot] Encryption solution for messages at rest

[Michael Orlitzky]

On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
> Hi,
> 
> We have clients with various security & compliance requirements.
> Although not required, it would be ideal to have messages encrypted
> at rest.

You can rule out a lot of the crazier options by answering the questions,

(a) What attack scenario do you have in mind?

(b) How will encryption help?

Re: [Dovecot] Encryption solution for messages at rest

[Michael Orlitzky]

On 10/28/2013 03:14 PM, Douglas Mortensen wrote:
> If a customer has vulnerable PHP code on a website, some of these
> will allow a remote file upload. I have seen cases where they upload
> a PHP script that is a sort of web-based console/shell to the server
> (file-system, etc.). It provides several tools which all run through
> the uploaded PHP script to try to brute force and do other attacks.
> I've seen attempts at a root exploit. We've never had a root exploit
> and any such case of a customer's site being hacked has been easily
> contained by simple filesystem permissions being correct (and the
> fact that we have apache setup to run all scripts as the user who is
> the owner of the script files, which confines the script to that
> users' permissions). Still nobody loves the idea of bad guys trying
> to hack on your box.

If an attacker gets root, the entire exercise is pointless, because he
can get the decryption key. So you "don't have to worry" about that case =)

A suggestion, not dovecot-related:

The web users -- in our case, www.example.com -- shouldn't have access
to anything outside of the web root. You can achieve this within PHP by
placing everything that the website will need under one directory, and
setting (in apache):

  php_admin_value open_basedir /var/www/$domain/$host/
  php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
  php_admin_value session.save_path /var/www/$domain/$host/tmp
  php_admin_value sys_temp_dir /var/www/$domain/$host/tmp

Personally, I don't trust PHP at all, so we create a separate web user
for each vhost and run them under mpm-itk .


> So given that type of scenario, if filesystem permissions weren't
> correct, or some new exploit surfaced that allowed someone bypass or
> elevate to root, then they could theoretically have access to the
> entire fileystem including where emails are stored.

Who has access to the maildirs on your systems? On ours, everything is
owned by deliver:deliver, with mode 700 or 600. The dovecot 'deliver'
user is the one who reads and writes all mail. (It is in fact a misnomer
now that we use LMTP). You can achieve the same by setting mode=600
everywhere in dovecot.conf, but this depends on your setup.

Suppose someone gains access to the 'deliver' user. That user is the one
who reads and would decrypt the mail; therefore the attacker can read
the mail anyway. But if they don't gain access to the 'deliver' account,
what can they do? Barring incorrect permissions or a kernel bug, nothing.

The permissions are handled by dovecot, which ostensibly you trust. And
if there's a kernel bug, you have bigger problems.

[Dovecot] OT: PHP session data storage

[Michael Orlitzky]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/28/2013 04:10 PM, Reindl Harald wrote:
>> 
>> php_admin_value open_basedir /var/www/$domain/$host/ 
>> php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp 
>> php_admin_value session.save_path /var/www/$domain/$host/tmp 
>> php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
> 
> oh no - do *not* place the sesiondata anywhere inside open_basdir 
> this is one of the badest things you can do because any otherwise 
> harmless script bypassed whatever security restriction will be able
> to read *any* session data
> 

You have a point, but I wouldn't go as far as to say it's one of the
worst things you can do. If a vulnerable PHP script allows an attacker
to (at least try to) read arbitrary files, then it's possible to read
session data that lies within open_basedir. Note that they can already
 read your database credentials out of config.php at that point.

But, if you put the session data under open_basedir, then it's easy to
restrict access to the entire /var/www/example.com hierarchy to the
one user that needs it: www.example.com. In the scenario I described,
I'm able to tell our customers that their websites are "physically"
separated from our other customers.

If there's a vulnerability in someone else's site, the kernel (via
filesystem ACLs) will prevent it from affecting yours. The web user
for example.NET truly cannot even traverse /var/www/example.COM, where
everything important to you is stored. This is robust against Apache,
Ruby, Python, etc. vulnerabilities as well -- not just PHP.

I already mentioned that I don't trust PHP. Our sites would be just as
secure if open_basedir stopped working tomorrow, since the filesystem
ACLs are what we trust to work. So, we trade the potential to read
sessions for that peace of mind. Not trying to downplay your
complaint, just pointing out another POV.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJSbvzxAAoJEBxJck0inpOi2AUQAJCnroIfBiaB1EIeV+X0wfE4
drfac6wdp16bQxRBQOj2if0qhG363bK3jVTwirEsSeWgmE9FBMDiiQeLe3txL4Nb
7NffcX/ThxM9i7Xwpd13ZMsmOlJiTbRg54AeLaBP7oUVnRd5wyaby60KyFDF9raN
LP8aYtVs2GR8tCG1tEbwfoOZGmAtRx8Ku7HiYHlUBiyHdFFg86svV//ShiHpp9+N
4m+1uDEyLsRZ8o9U7x7p/mAwB6sHLcRlQNIA5lHdI8eGqy3J/H+O61u9zs1a4YPS
XKUY6wkLc9ksuD56N+an+jT51+0KybyJTOh8m4ZjEhZLBdkhzkeLQkAkQ4XG0MLW
7IsEq6SpY7j/0jSI/DoXBu/dsY275J9BpciRisKBmmZQEybZqzrgUWyHrWSKa72R
OjiCnYCrnQj8q71k+U3jUKL+b4xChtrN6+JzIAbCdVjfu7UTaBquz0cN29EnopnB
HqzWLwqP1aXlBzlVBGvyVN8mQWDEbtKIMcH0FvT5UYR+YGKxhaEadVFRcqx2t+p/
zifIN1g4hn66V4nxv1ULi3nM1rze8RUbjj9cJL1xP+iEstJdfdo+Fz5GNnp2dq0t
E3lvghfv5fL9syaq7eanHU4W0sfF9IbtJ4cqbyzAKi5zBwWuk2tueQ1N1GX++CxG
mMFqEPKR6gkUGX/ooEIc
=iaNf
-END PGP SIGNATURE-

Re: [Dovecot] Encryption solution for messages at rest

[Michael Orlitzky]

On 10/30/2013 09:01 AM, Benny Pedersen wrote:
> Michael Orlitzky skrev den 2013-10-28 20:49:
> 
>>   php_admin_value open_basedir /var/www/$domain/$host/
>>   php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
>>   php_admin_value session.save_path /var/www/$domain/$host/tmp
>>   php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
> 
> so dont create tmp upload dirs in webroot, this is classic way of 
> showing no care
> 

DocumentRoot is /var/www/$domain/$host/public.

Re: [Dovecot] / vs.

[Michael Orlitzky]

On 05/17/2014 11:57 AM, Boris wrote:
> 
>> no - < reads a file and without you are supposed to directly
>> paste your certificate in the configuration instead point
>> to a file
> I see. In all other places I know dovecot references files simply with "/" so 
> I 
> still wonder what is so different in this case.
> 

In the other cases, the configurable parameter is supposed to be a path
to a file. So you give it a path, beginning with "/".

The certificate parameter takes  string, so you would have had to
copy/paste your certificate in there. But nobody wants to do that, so
there's an alternate way to read the certificate from a file.

Fictional example: it's the difference between:

  valid_users = us...@example.com, us...@example.com,...

and

  valid_users = 

Re: macros

[Michael Orlitzky]

On 07/11/2014 03:59 AM, Arkadiusz Miśkiewicz wrote:
> 
> Does dovecot support any form of macros? I would like to share configuration 
> file between several servers. Configs are different only in tiny aspects.
> 

As a last resort, you can use `make` to accomplish this.


  dovecot-server.conf.sh
  --
  id=55
  something="SELECT FROM * WHERE something"
  mechanisms="digest-md5"


  dovecot-main.conf.sh
  
  source ~/dovecot-server.conf.sh

  cat < $@

Re: ssl_cert: Can't open file permission denied

[Michael Orlitzky via dovecot]

On 4/10/19 6:39 AM, Dmitry Donskih via dovecot wrote:
> `chmod -R 655 /etc/foobar/ssl' drops x attribute from `ssl' itself.
> Use `chmod -R 755' or `chmod +x' or similar.
> 

Your private keys should be... private. Use 750 instead.