Thank you, Lukas Matasovsky, for isolating this. I've had dovecot pinned
to the .16 version since I started getting that crash in the .17
version. But I've been too slack to do more than scan the mailing list
for fixes. Your investigation provided the solution that also worked for
me. Once
Who delievers incoming mail, dovecot LDA or something else?
This is what caused a similar problem for me:
https://dovecot.org/list/dovecot/2016-April/104091.html
Bron Gondwana wrote on 11/27/2016 02:25 PM:
The demo proxy was a pretty quick hack and isn't very efficient, but
it should be working. It does a fairly slow background import for
existing accounts, so I'd recommend using small tests accounts. What
particular bit is broken for you? (apart from
I don't know the answer to that question, but I am curious about
something. What client are you thinking about using with JMAP? I haven't
found much. (And much of the demo stuff at jmap.io seems to be busted in
various ways.)
Andrew Jones wrote on 11/26/2016 10:43 AM:
Hi there,
I understand
I'd like to start offering my server's users multi-factor
authentication. Right now, I funnel all authentication through dovecot.
Before I get too far down the fantasy design path, I'm wondering if
anyone else has already done this and could share some details or code.
(I loaded up the subject
A long shot, but here's how I experienced similar symptoms:
http://www.dovecot.org/list/dovecot/2016-April/104091.html
Kamil Madac wrote on 08/23/2016 02:02 PM:
Hi,
One of my email accounts has 1,5gb of emails in INBOX, but maildirsize
shows only 528mb. 'du' also shows 1,5gb and there are
On 04/19/2016 07:17 PM, WJCarpenter wrote:
Is it by design that dovecot doesn't update maildirsize immediately
when messages are expunged? If yes, why?
Replying to my own question since I figured it out. Local config glitch,
not a dovecot bug or design fault.
I should have mentioned that I
This might be something that everybody thinks of as a well-known fact,
but I've been searching around quite a bit without finding anything
definitive. Maybe I just have the wrong idea of what's supposed to be
going on.
I'm using maildir+ quotas. For arriving mail, it works as I expect: new
The main reason I switched was so that I could move from procmail to
seive,
I am curious if you investigated Exim's sieve script support. Was there
some problem you saw with it, or you just didn't look into it?
On 11/08/2013 07:43 AM, Charles Marcus wrote:
On 2013-11-08 10:22 AM, Timo Sirainen t...@iki.fi wrote:
Ah, I had actually been mostly just thinking about inbound SMTP
features.
Hmmm well, I'd hate to see this turn into a huge time-sink for
you. The fact is, postfix's maturity combined
On 11/08/2013 10:46 AM, Charles Marcus wrote:
On 2013-11-08 1:35 PM, WJCarpenter bill-dove...@carpenter.org wrote:
I would probably be pretty skeptical and uninterested in a Dovecot
MTA. No offense. I think you should look at other existing MTAs
besides postfix before concluding
Was just perusing this article about how trivial it is to decrypt
passwords that are stored using most (standard) encryption methods (like
MD5), and was wondering - is it possible to use bcrypt with
dovecot+postfix+mysql (or posgres)?
Ooop... forgot the link:
On 1/3/2012 2:38 PM, Simon Brereton wrote:
http://xkcd.com/936/
As they saying goes, entropy ain't what it used to be.
https://www.grc.com/haystack.htm
However, both links actually illustrate the same point: once you get
past dictionary attacks, the length of the password is dominant factor
On 1/3/2012 5:25 PM, Charles Marcus wrote:
I think ya'll are missing the point... not sure, because I'm still not
completely sure that this is saying what I think it is saying (that's
why I asked)...
I'm sure I'm not missing the point. My comment was that password length
and complexity are
On 4/15/2011 5:36 PM, WJCarpenter wrote:
As far as I have been able to figure out, dovecot auth always works
over a Unix domain socket. I believe it is not currently possible to
operate dovecot auth over an Internet domain (TCP) socket. Am I correct?
I want to call dovecot's exported
On 4/15/2011 5:36 PM, WJCarpenter wrote:
I want to call dovecot's exported authentication from a Java
application. Java doesn't natively know how to talk to a Unix domain
socket, so there are inconveniences. There are 3rd party JNI
libraries to allow Java to do it, but I'm not too wild about
As far as I have been able to figure out, dovecot auth always works over
a Unix domain socket. I believe it is not currently possible to operate
dovecot auth over an Internet domain (TCP) socket. Am I correct?
I want to call dovecot's exported authentication from a Java
application. Java
Example:
* I have 100's of sent-mail mailboxes I don't want to be subscribed
to, because it is doubtful I will ever use them. These mailboxes are
unsubscribed because I don't want to see them in any mailbox listings
by default.
This use of subscriptions is a terrible abuse of IMAP. Like
Subscriptions themselves aren't an abuse of IMAP, obviously, as they
are in the spec. A client that *by default* uses them to hide folders
is abusing them, for exactly the reasons I explained. They are
non-portable because:
I agree 100% that hiding folders by default is bad, but I've never
http://wiki.dovecot.org/Migration/MailFormat shows a bunch of
scripts, one of them claims to preserve UIDs.
Does anyone here have direct successful experience with this? I only
asked about this because a comment on that same page says, None of
the solutions described below preserve the
I have two populations of dovecot users. Some users have Unix accounts (with
logins disabled), and so their password hashes are stored in /etc/shadow.
These days, the default configuration for that is salted SHA-512. It's easy
for me to change that scheme to something else if I want to,
On 1/29/2010 4:11 PM, WJCarpenter wrote:
http://wiki.dovecot.org/Migration/MailFormat shows a bunch of
scripts, one of them claims to preserve UIDs.
Does anyone here have direct successful experience with this? I only
asked about this because a comment on that same page says, None
BTW. Are you also using a script that preserves IMAP UIDs? Otherwise
IMAP clients will re-download all the mail.
Does the convert plugin preserve the UIDs? The wiki implies that it
doesn't, but I thought maybe since it's implemented as a plugin that
maybe it does (or that maybe the caution
BTW. Are you also using a script that preserves IMAP UIDs? Otherwise IMAP
clients will re-download all the mail.
Does the convert plugin preserve the UIDs? The wiki implies that it doesn't,
but I thought maybe since it's implemented as a plugin that maybe it does (or that maybe
the
http://wiki.dovecot.org/Migration/MailFormat shows a bunch of scripts, one of
them claims to preserve UIDs.
Does anyone here have direct successful experience with this? I only
asked about this because a comment on that same page says, None of the
solutions described below preserve
Step 4) Figure out if base64-encoded attachments can be decoded in a way
that allows re-encoding them back to the exact original encoding. If so,
save the attachment decoded and add the necessary encoding info the dbox
metadata.
Although you might like to do that for some sort of tidiness
I was thinking things like: upper vs. lowercase characters, different
line wrapping lengths, possibly some other weird stuff.. I'd think
that all digital signatures break if any of those change? Or do they
really parse the headers and do calculate the signatures using the
decoded base64?
Is there any option available for me to help inhibit/prevent
brute-force login attempts?
I (and many others) use fail2ban. It works outside of dovecot, et al,
by tailing your log files. When it finds a configurable number of
failed attempts in a configurable time window, it blocks the
Easy! Either connect to imap.tib.com instead of mail.tib.com, or
create and install a new security certificate on the server which is
for mail.tib.com instead.
Another solution is to obtain and install a wildcard certificate (which
will be good for all *.tib.com).
That's the good news.
2. It looks like any value at all for the proxy field in the passdb
lookup turns proxying on. The one exception is a value of NULL for
proxy, in which case proxying is not turned on and proxy-related
other fields are ignored. Is that how it's intended to work?
Yes. It might change in
It's even documented (somewhere) that NULL value means the same as
if the field wasn't even selected by the query.
Ah, so it is, on
URL:http://wiki.dovecot.org/PasswordDatabase/ExtraFields Not sure how
I missed that. Thanks.
?
If someone can give and informend confirmation that this is
as-designed, I can add some clarifying remarks on those points on the
wiki page.
Thanks.
--
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3
on different ports for
the two flavors of connections.
Can dovecot be configured to handle this and/or do we need to run
multiple instances of dovecot with different config files?
Thanks
--
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3
Patrick Ben Koetter wrote:
Ed W wrote:
Thanks to both for your comments; very helpful. I just wanted to make
sure it could work in practice before I spent some time on it. Sounds
like it can be done.
1.1, I
don't see a surefire way to do this. Has anyone done it, or can
anyone say for sure that it can't reasonably be done until
proxy_maybe?
Tx!
--
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3
Eg. when a customer says: Hey, I want my username to be foo, and my
email to be [EMAIL PROTECTED]. :)
I encourage that on my servers. It's just one more layer of defense
against password guessing zombies; beats me if it makes any difference.
I don't want to give them the userid for
My dovecot.conf sets
mail_location = maildir:~/Maildir/
dovecot has sometimes had trouble with ~. I use %h instead. (I think
there is a mention of this on one of the wiki pages.)
I don't recall if I changed to %h because I was having trouble or because I
wanted to avoid trouble.
ts The first line is also configurable in v1.1. Quota exceeded text
ts itself isn't though.
That's good since not every site wants to tell random outsiders that a
user's quota is full. I know it's common practice, but it's really a
holdover from the early days of email where there wasn't much
client, the dovecot proxy, and the destination server.)
--
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3
PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3
wjc Is there a way to configure dovecot's internal proxy connections
wjc to use STARTTLS or some other SSL/TLS level of security?
wjc (Without a
mmj Just create encrypted tunnel between the peers and send your
mmj traffic through it. IPSec, ssh etc..
Thanks for the suggestion. I had thought of
. Have you actually gotten its STARTTLS
to work? I tried it a couple days ago with no luck, but maybe I just
didn't try hard enough.
--
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3
(the default quota works fine, of course).
--
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3
Also, are there any drawbacks of using exim to do the local delivery?
I'm very interested in the answer to this question, too. So far I have found
(through reading, not trying things yet) that
Dovecot's quota handling is more flexible than Exim's (exim is pretty much
limited to FS quotas, I
I realize it's hard to be precise about this, but does anyone have a
feel or rule of thumb for a couple of aspects of indexing overhead?
1. Proportionally, how much space does it take for all 4 files? If I
want to give my users a quota of 100 MB for messages, how much real
space should I plan
I've been poking around the dovecot wiki, and this idea looks
plausible. I'm just double-checking with the assembled experts to see
if there is some gotcha that will happen to me down the road.
I have in mind a deployment of dovecot which will use serve several
unrelated domains. My plan is to
46 matches
Mail list logo
