Re: Dovecot and Thunderbird 15

[Tanstaafl]

Thunderbird 15? Either you you meant the brand new 115, you're using an
extremely old and long past supported version of Thunderbird...


On 8/9/2023 10:52 AM, Elise via dovecot wrote
> Hi,
> I recently had some issues with Thunderbird 15 when removing e-mail.
> With my other mailclient Outlook I could without any issue.
>
> As I don't grand POP3 mail pickup, I disabled that in dovecot.conf
>
> #service pop3-login {
> # inet_listener pop3 {
> #  address = 10.10.10.52
> #  }
> # inet_listener pop3s {
> #    address = 10.10.10.52
> #  }
> #}
>
> Enabling the above and restarting Dovecot solved the issue.
> Is it TB related or do I overlook a config parameter?
> E.
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: adding caldav/carddav next to dovecot

[Tanstaafl]

A HUGE second for SOGo

We used it for many years in a Gentoo/Dovecot/Postfix environment.

It was super fast/snappy, and extremely reliable, and works perfectly
with both Thunderbird AND Outlook (this was a huge plus for some of our
users who ridiculously preferred Outlook)...

they also offer implementation and ongoing support services at very
reasonable rates, but if you prefer to do everything yourself, the
documentation is perfectly adequate, and their email support list should
address any potential issues you might have.

SOGo rocks...


On 10/14/2022 3:35 PM, infoomatic wrote
> On 14.10.22 16:13, Marc wrote:
>> I also do not want any other other 'crap' just the cal (and card) dav 
>> solution.
> sorry about my suggestion, but I am just a big fan of SOGo (no
> affiliation with) from sogo.nu ... it may not be a solution for you
> because it offers caldav, carddav, webmail, but performance is top
> notch, maybe you want to have a look anyway
>

Re: Move sent emails to sent folder?

[Tanstaafl]

On 6/16/2022 7:33 PM, Austin Witmer wrote
> Hello all!
>
> I have a server running dovecot & postfix. I have a user on my server who is 
> sending email via smtp on an HP printer and because of that, a copy of the 
> email is not placed in the sent folder like usually happens with clients like 
> outlook and thunderbird.
>
> Is there any way to have the sent emails copied to the sent folder for just 
> this user on my server?

Doesn't dovecot now have the ability to be set up as a submission
service, and automatically place copies of sent messages to the Sent folder?

I could have sworn I saw this capability added a long time ago...

Re: Outlook vs Thunderbird

[Tanstaafl]

On Tue Jul 07 2020 02:07:08 GMT-0400 (Eastern Standard Time), Mark
Constable  wrote:
> FWIW I meant if the client is Windows7/old-Outlook then changing either
> 993/SSL or 143/STARTTLS to 143/NONE could help pick up the mail. We had
> to do this for a 100 or so clients a few months ago after upgrading to
> Ubuntu 20.04.

Really, really bad idea. You just disabled an/all security on your imap
connection.

Re: JMAP support

[Tanstaafl]

Fyi, JMAP support is now officially on Thunderbirds roadmap for 2021...

Ok, I'll say it...

Pretty please?!

On 7/9/2019, 1:36:58 AM, Aki Tuomi via dovecot  wrote:
> No ETA yet.
> 
> Aki
> 
> On 7.7.2019 1.12, Martynas Bendorius via dovecot wrote:
>> Hello,
>>
>> Is there any ETA set for JMAP support?
>>
>> Thank you!
>>
 On 11/27/2016 5:28 AM, Aki Tuomi  wrote:
 Hi!
 We are working on including JMAP support to Dovecot. At this moment I 
 cannot give any promise for exact version, but hopefully it will be part 
 of v2.3

 Aki Tuomi
 Dovecot Oy
>> --
>> Best regards,
>> Martynas Bendorius
>>
>>
> 

Updated Roadmap for Dovecot?

[Tanstaafl]

Hello,

Just wanted to go take a peek at the latest Roadmap for dovecot, and
note that the current wiki page is flagged as obsolete:

https://wiki.dovecot.org/Roadmap

Is there an updated version somewhere?

I'm interested in the list of new features being worked on - especially
JMAP support - and a rough idea of when said features might be expected
to make it into a release.

Thanks!

Re: Dovecot behind Load Balancer

[Tanstaafl via dovecot]

On 7/10/2019, 4:27:32 AM, Sami Ketola via dovecot 
wrote:
> There is a limit on thunderbird config that controls this.

And the default is 5 if memory serves...

Re: Stats/Metrics in 2.3

[Tanstaafl via dovecot]

On 6/2/2019, 1:46:37 PM, @lbutlr via dovecot  wrote:
> Yep, I just wasn’t sure how large that file might be (One mailing
> list didn’t like the inline 14,000 line log file for some
> inexplicable reason).
Well, there is a pretty big difference between a huge log file and a
small config file.

Every tech support list I've ever been on wants config files and log
snippets inline in the emails - this prevents loss of historical
data/context in the archives if/when the online repositories delete
referenced files.

For things like huge core dumps or wireshark captures, sure, if they are
huge, link them.

Re: Convert Maildir to Dbox?

[Tanstaafl via dovecot]

On Wed May 29 2019 02:00:24 GMT-0400 (Eastern Standard Time), Aki Tuomi
via dovecot  wrote:
> On 29.5.2019 8.17, @lbutlr via dovecot wrote:
>> Are you sure you read
>> it? https://wiki2.dovecot.org/MailboxFormat/dbox seems pretty clear.

> David, in particular, is there some question you feel that the wiki
> fails to answer?

I'm not David, but I just read the entire page and one thing that I was
specifically interested in has to do with the importance of the index files.

I seem to recall reading somewhere that dovecot saves more than one
version of the index files to reduce the chance of losing the indexes,
but I don't see anything about that.

Also - is it possible to configure dovecot to keep multiple copies?

I was also planning on putting the indexes on either a ZFS or BTRFS
partition to further reduce the chance of data loss (self-healing
preventing silent data corruption, and snapshots), but only saw a
comment that they can be stored in a different location, but nothing
about why you might want to do that - e.g., to use a more resilient
filesystem to store these critical files.

Another aspect I'd like to see is recommendations for backup strategies,
with respect to the fact that the indexes are so critical.

Re: JMAP support in Dovecot

[Tanstaafl via dovecot]

Thanks for chiming in Bron!

I'm very interested in JMAP as you can see, but I'm also very curious -
do you have any blog pages dedicated to the user experience vs standard
IMAP? How it differs - and most importantly if it is truly better, and
if so, how and why?

I'd also love to read about actual user experiences - how about a
collection of comments from your users?

Thanks again,

Charles

p.s. Even though I've always hosted my own, I'm very tempted to sign up
for a paid account to see for myself.



On Tue May 28 2019 03:49:25 GMT-0400 (Eastern Standard Time), Bron
Gondwana via dovecot  wrote:
> On Wed, May 22, 2019, at 23:43, Tanstaafl via dovecot wrote:
>> On Wed May 22 2019 05:44:59 GMT-0400 (Eastern Standard Time), Aki Tuomi
>> via dovecot  wrote:
>> > Unfortunately we have not been able to work on this much, but also the
>> > JMAP spec was until very recently still being worked. We have open
>> > dialogue with the Thunderbird people, they haven't so far indicated any
>> > pressing need for JMAP in Dovecot.
>> > 
>> > This said, JMAP is still very much in our roadmap. Perhaps just not as
>> > close as I initially thought.
>
> Obviously I'd love to help out in any way possible here!  We're very
> keen to see JMAP support in Dovecot to encourage others to move
> towards it as well.
>
>> Thanks Aki - no pressing need because of the old chicken/egg problem I
>> guess...
>>
>> That said, a few tidbits...
>>
>> The Thunderbird Devs are using Topicbox for discussing Thunderbird UI
>> development, and Topicbox is built directly on top of JMAP for the email
>> integration (I'm not sure they even knew this until I told them
>> yesterday):
>>
>> From: https://fastmail.blog/2018/12/27/jmap-is-on-the-home-straight/
>>
>> "But enough about the software, how about the experience! When we
>> created our brand new Topicbox product, we built directly on top of JMAP
>> for the email. We also used JMAP-inspired APIs for the rest of the
>> product experience, so Topicbox’s early users have been on JMAP for over
>> a year now."
>>
>> Lastly, Fastmail is now rolling it out - 30% of their userbase is on
>> JMAP, and all new users are automatically on it. Cyrus also provides
>> experimental JMAP support in their development snapshots.
>
> Actually, 99% of our user base has been on JMAP for about 4 months
> now!  The one remaining percent was users with the old version of our
> mobile apps, and they're being cut off next month.
>
> As for JMAP mail and JMAP core - they're currently with the RFC editor
> for the final round of edits - they should have assigned RFC numbers
> in the next few weeks I would imagine.  There will be some minor
> editorial polish, but the way it works is entirely stable now, there
> won't be more changes.
>
> https://datatracker.ietf.org/doc/draft-ietf-jmap-core/
> https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/
>
> We're planning to have full support for everything in those specs into
> Cyrus IMAP version 3.2 as well.  Right now there's a couple of gaps
> that we either don't use at FastMail or are papering around with our
> perl middleware.  You can see the remaining tasks here as we progress:
>
> https://github.com/cyrusimap/cyrus-imapd/labels/3.2
>
> Cheers,
>
> Bron.
>
>
>
> -- 
>   Bron Gondwana
>   br...@fastmail.fm
>
>

Re: How to get original recipient from Postfix when using LMTP?

[Tanstaafl via dovecot]

On Wed May 22 2019 13:34:42 GMT-0400 (Eastern Standard Time), MRob via
dovecot  wrote:
> On 2019-05-22 08:18, Tuomo Soini via dovecot wrote:
>> On Tue, 21 May 2019 18:24:46 +
>> MRob via dovecot  wrote:
>>
>>> Many people prefer to use LMTP for delivery from postfix for better
>>> efficiency but X-Original-to header support still missing after many
>>> years. One affect of this is need to set
>>> sieve_vacation_dont_check_recipient = yes which violate Sieve
>>> standard and cause auto-replyies sent to messages that should not
>>> happen. Or abandon LMTP. or abandon postfix??
>>>
>>> So while feature request is stalled are there any realistic
>>> workarounds?
>>
>> add to smtp_recipient_restrictions, before permitting email but after
>> all checks:
>>
>> check_recipient_access pcre:/etc/postfix/recipient_access.pcre
>>
>> # cat /etc/postfix/recipient_access.pcre
>> /(.+)/ prepend X-Original-To: $1
> 
> Warning, do not do this unless you don't mind recipients of 
> multi-recipient emails to see a list of everyone who got a copy of the 
> email message, including BCC recipients. This isn't a good solution if 
> you want to respect user privacy.

Bummer, I was actually glad to see a way to get the x-original-to when
using LMTP.

Guess I'm stuck with the LDA until this gets implemented.

Re: JMAP support in Dovecot

[Tanstaafl via dovecot]

On Wed May 22 2019 05:44:59 GMT-0400 (Eastern Standard Time), Aki Tuomi
via dovecot  wrote:
> Unfortunately we have not been able to work on this much, but also the
> JMAP spec was until very recently still being worked. We have open
> dialogue with the Thunderbird people, they haven't so far indicated any
> pressing need for JMAP in Dovecot.
> 
> This said, JMAP is still very much in our roadmap. Perhaps just not as
> close as I initially thought.

Thanks Aki - no pressing need because of the old chicken/egg problem I
guess...

That said, a few tidbits...

The Thunderbird Devs are using Topicbox for discussing Thunderbird UI
development, and Topicbox is built directly on top of JMAP for the email
integration (I'm not sure they even knew this until I told them yesterday):

From: https://fastmail.blog/2018/12/27/jmap-is-on-the-home-straight/

"But enough about the software, how about the experience! When we
created our brand new Topicbox product, we built directly on top of JMAP
for the email. We also used JMAP-inspired APIs for the rest of the
product experience, so Topicbox’s early users have been on JMAP for over
a year now."

Lastly, Fastmail is now rolling it out - 30% of their userbase is on
JMAP, and all new users are automatically on it. Cyrus also provides
experimental JMAP support in their development snapshots.

So, maybe - hopefully - this might be some reasons to push that
development up some.

if not, its good to know that it is at least still on the roadmap.

Re: JMAP support in Dovecot

[Tanstaafl via dovecot]

Hello Aki,

Well, it has been over 3 years since I last asked...

You had said initial JMAP support would hopefully make it into 2.3.
Since it didn't, I'm hoiping it isn't too far away.

There is some movement with the new Thunderbird team on this, but they
can't really start serious work on adding JMAP support until there is a
server implementation to test against.

Is JMAP support still hopefully on the near term roadmap?

Thanks

Charles

On Sun Nov 27 2016 05:28:36 GMT-0500 (Eastern Daylight Time), Aki Tuomi
 wrote:
> Hi!
> 
> We are working on including JMAP support to Dovecot. At this moment I cannot 
> give any promise for exact
> version, but hopefully it will be part of v2.3
> 
> Aki Tuomi
> 
> Dovecot Oy
> 
>> On November 26, 2016 at 11:17 PM Andrew Jones  wrote:
>>
>> Hi Marcus
>>
>> Thanks for your helpful reply.
>>
>> Do you know what is going on with JMAP development into Dovecot 2.5?
>>
>> It's difficult to get any sort of information from the roadmap and there are 
>> no Dovecot forums.
>>
>> One of the main reasons I'm interested in JMAP is because of Roundcube Next 
>> and also the other clients it will >> power. Sadly, there has been little 
>> going on and having emailed Thomas, he is no longer involved in Roundcube >> 
>> Next - which is a shame. The Kolab guys are really taking liberties here, 
>> and trying their product, the thing >> is littered with bugs everywhere.
>>
>> Are you able to comment on what is going on with JMAP development into 
>> Dovecot?
>>
>> Thanks 
>>
>> Andrew 

>>> On 26 Nov 2016, at 19:16, Marcus Rueckert  wrote:
>>>
 On 2016-11-26 11:07:00 -0800, WJCarpenter wrote:
 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.)
>>>
>>> roundcube-next builds on top of it.
>>>
>>>darix

Re: Permissions fix

[Tanstaafl via dovecot]

On Wed May 15 2019 12:58:39 GMT-0400 (Eastern Standard Time), Lefteris
Tsintjelis via dovecot  wrote:
> Is there a fast way for dovecot to set and/or fix its directory permissions?

I don't think so. I suggested dovecot implement something like postfix
does, but I believe the response was that there are too many variables
for there to be a reliable way for dovecot to do this automatically - at
least without a lot of work.

Re: Sis to deduplicate attachments does not work?

[Tanstaafl via dovecot]

On Wed Apr 24 2019 04:12:30 GMT-0400 (Eastern Standard Time), Daniel
Miller via dovecot  wrote:
> If you've got good hardware, including a proper UPS, I'd recommend dbox
> (my server is presently using sdbox). With large mailboxes and
> file-based backups you'll benefit from mdbox. When reliability is the #1
> concern above anything else - use maildir. Depending on your use SIS can
> have significant impact on storage requirements - but storage these days
> is relatively cheap.

My plan when I roll out my new server this year is to use mdbox, but put
the indexes and other important meta data on a smallish volume using
either ZFS or BTRFS, for the automatic self-healing capabilities (and
the ability to expand it if necessary).

This pretty much eliminates the worry about data loss from index file
corruption.

> I haven't seen much feedback from users actively using SIS - I'd love to
> hear from high traffic sites with SIS experience to know if the
> corruption issues have been resolved. In my case there was at least a
> 30% reduction in space but I had too many errors - admittedly it's been
> a couple years since I last tried it.

I never tried it because of the problems with respect to backup/restore,
and if I'm not mistaken, those problems have not been resolved.

Maybe its a design issue...

Or maybe it just isn't a high enough priority, like the missing
x-original-to header in the LMTP code that will still prevent me from
being able to use the otherwise much better LMTP delivery agent.

Re: [Dovecot] Dovecot LDA/LMTP vs postfix virtual delivery agent and the x-original-to header

[Tanstaafl via dovecot]

Sadly, I guess not...

I'm not sure what to make of this, seeing as both Wietse and Timo said
it was almost a trivial thing to fix.

On Fri Apr 12 2019 12:17:22 GMT-0400 (Eastern Standard Time), Tanstaafl
via dovecot  wrote:
> I'm resurrecting this again because I'm getting pretty close to possibly
> being ready to install a brand new dovecot server (finally), but I still
> need for dovecots LMTP to add the x-original-to header.
> 
> So... was this completed quietly, or is support for it still not there?
> 
> Thanks,
> 
> Charles

Re: Fwd: SOLR/Index?

[Tanstaafl via dovecot]

On 4/15/2019, 6:59:59 AM, Larry Rosenman via dovecot
 wrote:
> If I login to roundcube with @lerctr.org  it
> finds the autoindexed mail.
> 
> So, if I make everyone always authenticate as @lerctr.org
>  we should be fine.

You can configure roundcube to always use the fqdn...

Re: [Dovecot] Dovecot LDA/LMTP vs postfix virtual delivery agent and the x-original-to header

[Tanstaafl via dovecot]

I'm resurrecting this again because I'm getting pretty close to possibly
being ready to install a brand new dovecot server (finally), but I still
need for dovecots LMTP to add the x-original-to header.

So... was this completed quietly, or is support for it still not there?

Thanks,

Charles

On Tue Apr 28 2015 15:27:07 GMT-0400 (Eastern Standard Time), Charles
Marcus  wrote:
> On 4/28/2015 1:40 PM, Tobias Franzén  wrote:
>> On 2014-01-08 14:32, Charles Marcus wrote:
>>> On 2012-04-09 8:53 AM, Timo Sirainen  wrote:
 On 9.4.2012, at 15.50, Charles Marcus wrote:
>> LMTP adds a new Delivered-To:  header when there is
>> a single RCPT TO. You can force a single RCPT TO from Postfix side by
>> setting lmtp_destination_recipient_limit=1. LMTP doesn't
>> add/remove/change X-Original-To: header.
> Ok, thanks Timo... but...
>
> Are you saying that this 'Delivered-To:' header can somehow be 
> leveraged to provide the same info as the x-original-to header?
 I guess X-Original-To is the same address as what Postfix sees as the 
 original RCPT TO address before alias expansion and such? In that 
 case, see my today's mail in Postfix list..
>>> Hi Timo,
>>>
>>> I just tried to find your email from that day, but don't see it in the 
>>> archives...
>>>
>>> Was this ever resolved (getting x-original-to support in LMTP, like it 
>>> is for the LDA)?
>>>
>>> If not, since it seemed like it wasn't going to be much work, any 
>>> chance you can revisit it soon?
>> Hello,
>>
>> I have tried to keep tabs on the various discussions going on related to 
>> the X-Original-To header when using Dovecot LMTP. Until now I have not 
>> needed a solution, but I am now finally about to migrate my old server.
>>
>> Old setup: Postfix + SpamAssassin (after-queue content filter via pipe) 
>> + virtual transport, and Courier-IMAP.
>> New setup: Postfix + amavisd-new (after-queue content filter via smtp, 
>> with ClamAV and SpamAssassin) + Dovecot LMTP, and Dovecot for IMAP.
>>
>> Charles, have you found a way that works for you?
> 
> No, and I simply haven't switched to LMTP yet, for this and one other
> reason (political, not technical)...
> 
> As for the rest below... wow... all I can say is, it sure would be nice
> if Timo/Wietse could just add the few lines of code that Timo said would
> be needed to properly support it natively.
> 
>> I was experimenting some with my test server and came up with a way that 
>> utilizes some additional internal smtp content filter forwarding, which 
>> produces some overhead. It should be light compared with the load from 
>> ClamAV and SpamAssassin, however.
>>
>> I'm not yet sure how amavisd-new funneling would handle multiple local 
>> recipients with different settings without passing the mail through 
>> multiple time, at least once per local user, let alone without first 
>> performing address mapping in postfix (for alias expansion). I have 
>> configured per-user SpamAssassin bayes filtering, and may introduce a 
>> whitelist based on address book entries (Roundcube.)
>>
>>
>> This solution I'm currently testing will pass each message through 
>> amavisd-new one time each per local and remote recipient, and will only 
>> add the X-Original-To header to the specific local recipient each 
>> envelope is intended for. No external users will receive the header, and 
>> no local user will see which other local users (e.g. via BCC) have 
>> potentially received the same message.
>>
>> Flow:
>> all mail in (both external and tls-authenticated internal) -> smtp (1) 
>> -> smtp-split (2) -> smtp-to-me (3a) | smtp-to-external (3b) -> 
>> smtp-amavis (4) -> dovecot-lmtp (5)
>>
>> 1) I rely on default_destination_recipient_limit=1 in main.cf to split 
>> each incoming mail into one stream per recipient.
>> 2) smtp-split will receive one stream per recipient. Default 
>> content_filter=smtp-to-me, followed by option 
>> "smtpd_recipient_restrictions=permit_auth_destination,check_recipient_access,pcre:/usr/local/etc/postfix/filter-to-external.pcre,permit_mynetworks,reject"
>>  
>> means I stop processing restrictions if my server is the destination. If 
>> my server is not the destination, the FILTER in check_recipient_access 
>> will override the preceding smtp-to-me filter.
>>
>> Both 1) and 2) smtpd instances include option 
>> receive_override_options=no_address_mappings, to wait with mapping to 
>> internal recipient until we can add X-Original-To header for my server's 
>> users only.
>>
>> 3a) For mail to my server, smtp-to-me will add X-Original-To using a 
>> pcre script, in a similar fashion to step 2's filter. This step also 
>> expands the address mapping (by not specifying any 
>> receive_override_options).
>>-o 
>> smtpd_recipient_restrictions=check_recipient_access,pcre:/usr/local/etc/postfix/recipient_access_x-orig.pcre,permit_mynetworks,reject
>>
>> 3b) For mail leaving my server, smtp-to-external will not add any 
>> processing besides impl

Re: Restoring mailboxes from backup duplicates messages in POP clients

[Tanstaafl via dovecot]

On Wed Apr 10 2019 11:14:29 GMT-0400 (Eastern Standard Time), @lbutlr
via dovecot  wrote:
> On 10 Apr 2019, at 08:59, Tanstaafl via dovecot  wrote:
>> On Wed Apr 10 2019 09:13:41 GMT-0400 (Eastern Standard Time), Luis F. V.
>> Gomes via dovecot  wrote:
>>> I had a disk problem and had to reformat it. All mailboxes were backed 
>>> up using rsync.
>>> After I restored the mailboxes, the POP clients (Thunderbird) that 
>>> were configured to leave the messages on the mailserver for, let's 
>>> say, 30 days, didn't understand that some messages were already 
>>> transfered and the users got duplicated messages in their Inbox.
>>> How can we avoid this?

>> Don't use rsync, use the built in dovecot backup capability?

> Also, don't use POP3?

Well, I can at least understand the argument for someone wanting to use
POP3, but that is beside the point... rsync won't retain the message
UUIDs, while Dovecots backup will, thereby preventing POP3 users
redownloading the emails.

Re: Restoring mailboxes from backup duplicates messages in POP clients

[Tanstaafl via dovecot]

On Wed Apr 10 2019 09:13:41 GMT-0400 (Eastern Standard Time), Luis F. V.
Gomes via dovecot  wrote:
> I had a disk problem and had to reformat it. All mailboxes were backed 
> up using rsync.
> After I restored the mailboxes, the POP clients (Thunderbird) that 
> were configured to leave the messages on the mailserver for, let's 
> say, 30 days, didn't understand that some messages were already 
> transfered and the users got duplicated messages in their Inbox.
> How can we avoid this?

Don't use rsync, use the built in dovecot backup capability?

Re: Using lmtp to authenticate email users

[Tanstaafl via dovecot]

On Thu Mar 28 2019 17:04:37 GMT-0400 (Eastern Standard Time), Patrick
Mahan via dovecot  wrote:
> Hmm, actually it is set -
> 
> root@ns:/usr/local/etc/dovecot # dovecot -a | grep auth_username_format
> auth_username_format = %Ln

Use doveconf, not dovecot (although they may do the same thing).

doveconf -a just shows you ALL settings, regardless of whether or not
they are set in your particular config.

doveconf -n shows you the settings that your running dovecot is actually
using.

Re: Migration

[Tanstaafl]

On 12/31/2018, 5:22:48 AM, Ignacio García  wrote:
> A totally different approach (that is imap-server agnostic), providing 
> that you're setting up those new accounts with temporary passwords 
> (which you know), before users change their passwords to their liking: 
> you could also use imapsync ( https://github.com/imapsync/imapsync) . We 
> here use it with a batch file and a text file containing all accounts to 
> do mass-migrations, usually at night, when there's little to none user 
> interaction with their mail accounts. I like this approach because mail 
> service never gets interrupted and we do programmed syncs all night in 
> case DNS propagation takes more than expected and mail still arrives to 
> the old server.

Or, you can use Master Passwords on both sides, and just do the
migration at your leisure. I did this when migrating from our dovecot
server to Office 365.

Next time I'll look at using a dovecot method (DSync? doveadm?) but
still using Master Passwords.

Re: Solr

[Tanstaafl]

On 1/3/2019, 3:07:18 PM, Daniel Miller via dovecot 
wrote:
> On 1/3/2019 10:56 AM, Tanstaafl wrote:
>> On 12/21/2018, 11:19:42 AM, Daniel Miller via dovecot
>>  wrote:
>>> There is a *huge* difference between a functional Solr setup & squat
>> Interesting. Care to elaborate?
> 
> This is one of those things that has to be experienced to be 
> understood.  When you can perform an FTS search across (pause while I 
> check current stats...):
> 
> du -c -h /var/mail        136G
> 
> Solr numDocs:        520102
> 
> and using any IMAP client that supports server-side searches (like 
> Thunderbird & AquaMail) the results are basically instantaneous...it's 
> worth the effort.  And that's searching a Dovecot virtual folder defined 
> as "* all", including all my archives, all my list subscriptions, and 
> all the shared Inbox/Sent folders from my other users.
> 
> But I certainly wish it was easier to setup.

Thanks Daniel...

So, as one who has no experience of the benefit of either...

How does this compare with Squat? Meaning, Is it exponentially faster?
Twice as fast?

Re: Solr

[Tanstaafl]

On 12/21/2018, 11:19:42 AM, Daniel Miller via dovecot
 wrote:
> There is a *huge* difference between a functional Solr setup & squat

Interesting. Care to elaborate?

Re: Solr

[Tanstaafl]

On Wed Dec 05 2018 07:35:39 GMT-0500 (Eastern Standard Time), Joan
Moreau via dovecot  wrote:
> Why making squat obsolete ? It is simple and straightforward

Because no one has stepped up to maintain it?

Re: Cannot make disable_plaintext_auth = no works in configuration

[Tanstaafl]

Please keep list communications on list.

If your doveconf -n doesn't reflect the changes you are making, then you
are editing the wrong file.

On Mon Nov 12 2018 10:22:45 GMT-0500 (Eastern Standard Time), Steve
Leung  wrote:
> The doveconf -n did not show this setting, which I suppose it is keeping
> the default value.
> 
> Thanks
> 
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
> 
> On Mon, Nov 12, 2018 at 6:51 AM, Tanstaafl
>  wrote:
> On 11/11/2018, 4:02:25 AM, Steve Leung  <mailto:steveleung...@yahoo.com>> wrote:
> 
> > Hi,
> >
> > No matter how I try, I cannot make the config disable_plaintext_auth =
> > no to work. I have set it up in 10-auth.conf but when I check with
> > doveconf -a it is still disable_plaintext_auth = yes.
> 
> 
> As expected.
> 
> doveconf -a shows all DEFAULT settings
> 
> doveconf -n shows your custom/current settings being used by the running
> dovecot system.
> 
> What does doveconf -n show?
> 

Re: Cannot make disable_plaintext_auth = no works in configuration

[Tanstaafl]

On 11/11/2018, 4:02:25 AM, Steve Leung  wrote:
> Hi,
> 
> No matter how I try, I cannot make the config disable_plaintext_auth =
> no to work. I have set it up in 10-auth.conf but when I check with
> doveconf -a it is still disable_plaintext_auth = yes.

As expected.

doveconf -a shows all DEFAULT settings

doveconf -n shows your custom/current settings being used by the running
dovecot system.

What does doveconf -n show?

Re: Best way to move mail from one server to another

[Tanstaafl]

Never mind, should have waited and read the entire thread...

On Wed Sep 26 2018 09:52:26 GMT-0400 (Eastern Standard Time), Tanstaafl
 wrote:
> Finally have some time to review list emails...
> 
> On Tue Sep 04 2018 03:41:50 GMT-0400 (Eastern Standard Time), Sami
> Ketola  wrote:
>> imapsync always loses data.
> 
> Hi Sami,
> 
> Can you expand on this?
> 
> I used ImapSync to migrate from Dovecot to Office365 a couple of years
> ago, and didn't notice any issues with it at all.
> 

Re: Best way to move mail from one server to another

[Tanstaafl]

Finally have some time to review list emails...

On Tue Sep 04 2018 03:41:50 GMT-0400 (Eastern Standard Time), Sami
Ketola  wrote:
> imapsync always loses data.

Hi Sami,

Can you expand on this?

I used ImapSync to migrate from Dovecot to Office365 a couple of years
ago, and didn't notice any issues with it at all.

Re: Set X-Original-To based an ORCPT?

[Tanstaafl]

I really wish  this was foxed. this is the only thing preventing me from
using LMTP...

On Tue Aug 07 2018 09:29:18 GMT-0400 (Eastern Standard Time), Tom Sommer
 wrote:
> On 2018-08-07 13:07, Marco Giunta wrote:
>> Hi,
>> to get a 'Delivered-to' header based on ORCPT, I wrote a patch
>> (attached) to force Dovecot lmtp to advertise DSN after a LHLO command.
>> In this way, Postfix add an ORCPT to the RCTP command
>> (http://postfix.1071664.n5.nabble.com/pipe-flags-vs-lmtp-td11587.html#a11596).
>>
>> Be carefully: in this way DSN notification is broken, but they were
>> broken in any case at the time I wrote the patch (read the entire post
>> linked above).
>>
>> The first patch is for Dovecot 2.2.x: after apply, you cannot disable
>> the DSN advertisement. The other is for Dovecot 2.3.0: you can
>> enable/disable the advertisement using the new bool parameter
>> 'lmtp_lhlo_dsn'.
> 
> Interesting that support is actually built in, but simply not 
> advertised.
> 
> https://github.com/dovecot/core/commit/38f624b427aa8b6fad3765e6efd97c85a7f97a09
> 
> Maybe there is a plan?
> 
> --
> Tom
> 

Re: new problem

[Tanstaafl]

On Wed Jun 13 2018 18:49:18 GMT-0400 (Eastern Standard Time), Walter
Ulmke  wrote:
> 1) my inbox is "Posteingang". should I officially declare it somewhere?



> WHERE IS THE SERVER LOG?

Ummm... have you ever managed a mail server before?

If so, I think you need to start with the very basics, and RTFM - more
than once maybe.

If not, then that is your problem...

Permissions issues - was Re: Cannot delete folder

[Tanstaafl]

On Mon May 21 2018 14:20:51 GMT-0400 (Eastern Standard Time), Linda A.
Walsh  wrote:
> Yves Goergen wrote:
>> The issue still exists. Can anybody explain to me why dovecot creates 
>> IMAP folders with the wrong filesystem permissions?
> On a lark, I looked through my dirs @ permissions.  Shorted lines a bit 
> so they'd fit w/o extra lines between them using:
> (get rid of text before permissions, and shorten user/group to a few letter)
> find . -type d -ls|sed -r 's/^\s*\S+\s+\S+\s+// ; s/linda(group)?/usr/g'

I repeat something from a similar thread from last year...

It would be nice if Dovecot had something like Postfix's set-permissions
command to automatically fix permissions issues.

Dovecot may be a little more complicated and have more possible ways
things could be configured, but the possibilities are finite (aren't
they?) so this could be handled by defining the different possibilities
and having a conf option you can set to tell dovecot what scheme you are
using (or if possible, some way to auto-detect it and fall back to
spitting out an error asking you to define it manually if it can't).

Re: expiring mail from root's Maildirs?

[Tanstaafl]

On Fri May 04 2018 10:59:22 GMT-0400 (Eastern Standard Time), LuKreme
 wrote:
> The mail is crontab mail that is sent out to users via mutt. What would be 
> the "right” way to do this? (The cron tasks run as root because they are 
> scanning system logs on behalf of certain users and those scans cannot be run 
> as the user.)

Alias the local 'root' user to another account. This is best practice
anyway...

Re: SIS and Filesystem level backups (was just Re: Filesystem level backups?)

[Tanstaafl]

Bummer, apparently things haven't changed (for the better) with respct
to backup sand SIS...

:(

On 4/9/2018, 12:28:31 PM, Tanstaafl  wrote:
> On 4/9/2018, 11:34:40 AM, Ivan Warren  wrote:
>> Le 4/9/2018 à 4:56 PM, DurgaPrasad - DatasoftComnet a écrit :
>>> Does doveadm backup backup the attachments as well when using SIS? 
> 
>> As far as I know, it does (it de-shares shared attachments)
>>
>> I've used that solution to stop using SIS at one point (it created
>> more problems than it solved - especially permission issues)
> 
> Hi Ivan,
> 
> Mind if I ask for details?
> 
> (and maybe Aki or Timo):
> 
> I was considering implementing SIS on a new server I'm planning (won't
> be for a few months now probably). I had decided against it a long time
> ago because it was new, and there were drawbacks (backups not being
> properly accounted for being one of the big ones). I was hoping it had
> matured a lot since then and the drawbacks at the time were mostly
> history. Maybe that is not the case?
> 
> If not, are there open bugs dealing with the issues, and plan for
> addressing them? Or is SIs just probably not ever going to be ready for
> prime time?
> 

SIS and Filesystem level backups (was just Re: Filesystem level backups?)

[Tanstaafl]

On 4/9/2018, 11:34:40 AM, Ivan Warren  wrote:
> Le 4/9/2018 à 4:56 PM, DurgaPrasad - DatasoftComnet a écrit :
>> Does doveadm backup backup the attachments as well when using SIS? 

> As far as I know, it does (it de-shares shared attachments)
> 
> I've used that solution to stop using SIS at one point (it created
> more problems than it solved - especially permission issues)

Hi Ivan,

Mind if I ask for details?

(and maybe Aki or Timo):

I was considering implementing SIS on a new server I'm planning (won't
be for a few months now probably). I had decided against it a long time
ago because it was new, and there were drawbacks (backups not being
properly accounted for being one of the big ones). I was hoping it had
matured a lot since then and the drawbacks at the time were mostly
history. Maybe that is not the case?

If not, are there open bugs dealing with the issues, and plan for
addressing them? Or is SIs just probably not ever going to be ready for
prime time?

Re: Disable SIS

[Tanstaafl]

On Wed Mar 14 2018 15:17:58 GMT-0400 (Eastern Standard Time), Nick
Rosier  wrote:
> I'm currently running a small home-server with Dovecot. A long time ago 
> I configured it with SIS enabled. I would like to stop using SIS.
> 
> If I remove sis from mail_attachment_fs will the old mails that are 
> stored in SIS-storage still be accessible?
> How can I convert all mailboxes to stop using SIS and store attachments 
> back in the mails?

As one who used Dovecot years ago without SIS (it still wasn't well
baked) but was very interested in it, I'm curious why you want to stop
using it?

Re: Assertion during dsync receive

[Tanstaafl]

On Tue Mar 13 2018 08:12:29 GMT-0400 (Eastern Standard Time), Aki Tuomi
 wrote:
> On 13.03.2018 14:10, Tanstaafl wrote:
>> Yes... per folder? Or per user?
> Sorry, ment per folder. =)

Heh, no worries, ok, thanks, nothing to worry about so much then.

Re: Assertion during dsync receive

[Tanstaafl]

On Tue Mar 13 2018 07:42:31 GMT-0400 (Eastern Standard Time), Aki Tuomi
 wrote:
>> Is this index file kept on a per *folder* basis? Or per user/account?

> Yes

Yes... per folder? Or per user?

>> If it is per folder, then it is much less of a problem, and could be
>> worked around simply by moving messages around (say, archiving).

> It can help. But if you are not accessing all the mails e.g. migrating
> them, you can usually just rm the cache file and it'll probably won't
> grow fast back.

So, how would doing this impact performance? If it doesn't much, then
maybe a simple script to test the size and delete when it gets larger
than (whatever you like)?

Thanks Aki!

Re: Assertion during dsync receive

[Tanstaafl]

On Sat Feb 24 2018 11:32:05 GMT-0500 (Eastern Daylight Time), Aki Tuomi
 wrote:
>> On 23 February 2018 at 23:12 Tanstaafl  wrote:
>> Ok, so, I'm still unclear...
>>
>> what cache are we talking about? Are you saying that there is a limit to
>> how many emails dovecot can store in a single... 'folder'?

> Dovecot has cache for commonly fetched fields. This is called
> dovecot.index.cache. The maximum file size for the cache is about 4G,
> the maximum offset is 0x4000 * 4, because all offsets are divided by
> 4. If the cache file becomes full, there are things you can do..
> 
> 1. you can rm the cache file and hope it does not get full again too
> fast. 2. remove some mails

Ok, so... I'm *still* unclear, and please understand I'm not trying to
be difficult, but I want/need to understand this. One thing not helping
is I don't have a working dovecot setup I can access to go peek at the
filesystem, which would probably let me answer this for myself.

When you say 'commonly fetched fields', can you confirm this means it is
simply the number of emails that can cause the problem?

Is this index file kept on a per *folder* basis? Or per user/account?

If it is per folder, then it is much less of a problem, and could be
worked around simply by moving messages around (say, archiving).

Thanks again

Re: Really slow IMAP performance

[Tanstaafl]

On Sat Feb 24 2018 17:01:01 GMT-0500 (Eastern Standard Time), @lbutlr
 wrote:
> On 2018-02-24 (07:14 MST), Aki Tuomi  wrote:
>>
>> https://wiki2.dovecot.org/Migration/MailFormat
> 
> That didn't show up when searching wiki2 for "Migration" :/

Don't search 'wiki2', search just wiki.dovecot.org

I never liked the way Timo rolled out the wiki for the new version 2
when he did, I knew it would do nothing but create confusion...

Really, he should just redirect all references to wiki2 to wiki and kill
the old content...

Re: Assertion during dsync receive

[Tanstaafl]

On Fri Feb 23 2018 14:53:53 GMT-0500 (Eastern Standard Time), Aki Tuomi
 wrote:
> It is problem for any mailbox

Ok, so, I'm still unclear...

what cache are we talking about? Are you saying that there is a limit to
how many emails dovecot can store in a single... 'folder'?

Re: Assertion during dsync receive

[Tanstaafl]

On Fri Feb 23 2018 13:53:27 GMT-0500 (Eastern Standard Time), Aki Tuomi
 wrote:
> Once you cache grows bigger than 0x400 you have problems

This is for a single mailbox? IS this only a problem for mbox and maybe
sdbox?

Re: Optimizing search performance for mobile devices / web mailer / general - solr plugin config

[Tanstaafl]

On Fri Feb 23 2018 03:51:37 GMT-0500 (Eastern Standard Time), Peter
Chiochetti  wrote:
> There is a trick to have messages indexed on arrival, instead of at 
> mailbox access, "fts_autoindex = yes" in the plugin section. This is not 
> mentioned in the dovecot wiki page but might be useful.

Not sure why you would say that...

That setting is mentioned specifically twice...

https://wiki.dovecot.org/Plugins/FTS

Re: Questions about SPECIAL-USE IMAP extension

[Tanstaafl]

On Wed Jan 17 2018 15:56:39 GMT-0500 (Eastern Standard Time), Joseph Tam
 wrote:
> Thanks.  How does this manifests itself: the client gets an inconsistent
> view of the outgoing mailbox that depends on which mailbox the client
> is using, or the optimization is broken and dovecot keeps having to
> (re)read the mailbox to acquire the IMAP STATUS?

The way I think this should work is simple...

If the Client doesn't request one of the pre-defined 'aliases' for a
special use folder, then it simply does what it does now - uses what it
wants (creates it if it doesn't exist).

As far as I can tell, this would require dovecot to add some 'smarts'
with respect to virtual folders, and be able to create these on the fly
for clients, as virtual folders is how I think these special-use aliases
should be presented to the client, unless someone has a better idea.

So, for example, if a client asks for a special use folder that did not
use to be pre-defined (Admin added it sometime after the client
connected before), it moves any emails currently residing in the real
version of what will be the new 'alias' (virtual) folder to the alias
target (the real special use folder on the filesystem), deletes the real
version, then creates and subscribes to the new virtual folder.

As I said, properly coded, this could be painless and mostly invisible
to the client.

Re: Questions about SPECIAL-USE IMAP extension

[Tanstaafl]

On Mon Jan 15 2018 18:11:24 GMT-0500 (Eastern Standard Time), Joseph Tam
 wrote:
> Tanstaafl  writes:
> 
>>> Is this what you are looking for?
>>>
>>> https://wiki2.dovecot.org/Plugins/MailboxAlias
>>>
>>> It seems already be implemented...
>>
>> A first step maybe, but no, not quite.
> 
> So what are the gotchas of using this?
Read? From the link:

"This doesn't magically solve the problem of showing clients e.g.
multiple Sent mailboxes, but it can be used to make sure that all of the
different variants will have the same mails in them. Unfortunately it
also means that some clients will download the same mails to local cache
multiple times."

> How much does this free lunch cost?

? However much time it takes you to implement it?

Re: Questions about SPECIAL-USE IMAP extension

[Tanstaafl]

On Fri Jan 12 2018 17:02:29 GMT-0500 (Eastern Standard Time), Joseph Tam
 wrote:
> Tanstaafl  wrote:
> 
>> There was a similar discussion about this on list some time ago, about
>> whether or not Dovecot could utilize special use 'aliases' that your
>> clients may want to use by default, and Dovecot would automatically map
>> those requests to a single mailbox.
>> ...
>> Personally I would love to see this implemented.

> Yeah, that would be cool.  For an existing installation, though, an admin
> might have merge all existing mailboxes into the one actual mailbox to
> keep the confusion down.

Actually, properly coded and configured, I don't see why this couldn't
be handled automatically by dovecot.

Re: Questions about SPECIAL-USE IMAP extension

[Tanstaafl]

On Fri Jan 12 2018 15:58:06 GMT-0500 (Eastern Standard Time), Pedro
Ribeiro  wrote:
> Is this what you are looking for?
> 
> https://wiki2.dovecot.org/Plugins/MailboxAlias
> 
> It seems already be implemented...

A first step maybe, but no, not quite.

Re: Questions about SPECIAL-USE IMAP extension

[Tanstaafl]

On Fri Jan 12 2018 01:29:37 GMT-0500 (Eastern Standard Time), Steffen
Kaiser  wrote:
> On Thu, 11 Jan 2018, Joseph Tam wrote:
>> I'd like to configure my dovecot service to use the IMAP SPECIAL-USE

> well, in my experience SPECIAL-USE is just a suggestions to clients. Check 
> RFC 6154 for MUSTs, you'll find only few. Hence, how the client (or the 
> server) behaves in a special case is implementor-defined.
> 
> I do expect that any client supporting SPECIAL-USE honors the server 
> setting (first time it connects to the server or everytime, but at least 
> once) and creates the mailboxes it uses itself.
> 
> Otherwise, Dovecot can autocreate the mailboxes regardless of its use: 
> https://wiki2.dovecot.org/MailboxSettings

There was a similar discussion about this on list some time ago, about
whether or not Dovecot could utilize special use 'aliases' that your
clients may want to use by default, and Dovecot would automatically map
those requests to a single mailbox.

E.g.:

Outlook clients would see/use 'Sent Items'

Thunderbird would see/use 'Sent'

But both would be mapped to a single mailbox 'Sent' (or whatever you had
defined as the actual mailbox).

Personally I would love to see this implemented.

Re: New Dovecot service: SMTP Submission (RFC6409)

[Tanstaafl]

On 12/22/2017, 1:19:45 AM, Aki Tuomi  wrote:
> Tanstaafl, maybe you could explain what you think the BURL/URLAUTH
> stuff is for, or do you have some particular use case you would be using
> it? Client support already is not required, and yes, it might take a
> long time before clients support it.

Hi Aki,

I would primarily just like to be able to disable 'Save to Sent' action
in Thunderbird for accounts using a backend Dovecot+Postfix server that
supports this.

So, I guess I'm really confused about exactly what this is and how it
will work.

The reason I thought that Client support was required was this:

On 12/12/2017, 1:39:08 PM, Stephan Bosch  wrote:
> However, keep in mind that for this particular feature we're just
> providing the "chicken" as it were. The "egg", i.e. client support, is
> still to come. Apart from Trojita (which I think is still not widely
> used), I know of no IMAP client supporting BURL/URLAUTH for message
> submission. I'd expect to see it first for clients that can truly
> benefit; i.e., mobile clients such as K9.

So, maybe this doesn't mean what I thought it meant... ?

Thank

Re: New Dovecot service: SMTP Submission (RFC6409)

[Tanstaafl]

On Sat Dec 16 2017 15:41:25 GMT-0500 (Eastern Standard Time), Tanstaafl
 wrote:
> Ok, well, my ignorance is probably glaring here, but what I meant was,
> the make the BURL/URLAUTH pieces strictly between Dovecot and the
> backend SMTP server, make it invisible to the Client...

So, I take it the no response to this means that there is no way to put
the BURL/URLAUTH parts such that only server support is needed, nothing
special on the client side?

Bummer, that means it will be a looong time if ever that this feature is
usable.

Re: New Dovecot service: SMTP Submission (RFC6409)

[Tanstaafl]

On 12/16/2017, 5:10:14 AM, Stephan Bosch  wrote:
> Op 12/14/2017 om 6:07 PM schreef Tanstaafl:
>> One other point.
>>
>> Adding support for something like this that also requires Clients to add
>> support for it is just begging for a feature that never gets used.
>>
>> Stephan, are you sure there is no (fairly simple) way to make this an
>> SMTP service that any email client that supports SMTP can use?
> 
> It already is a normal compliant SMTP submission server. Just the BURL
> part is something that requires additional client support.

Ok, well, my ignorance is probably glaring here, but what I meant was,
the make the BURL/URLAUTH pieces strictly between Dovecot and the
backend SMTP server, make it invisible to the Client...

Re: New Dovecot service: SMTP Submission (RFC6409)

[Tanstaafl]

One other point.

Adding support for something like this that also requires Clients to add
support for it is just begging for a feature that never gets used.

Stephan, are you sure there is no (fairly simple) way to make this an
SMTP service that any email client that supports SMTP can use?


On 12/14/2017, 10:57:44 AM, Tanstaafl  wrote:
> On 12/14/2017, 3:03:41 AM, Aki Tuomi  wrote:
>> On 13.12.2017 21:41, Tanstaafl wrote:
>>> On 12/12/2017, 1:39:08 PM, Stephan Bosch  wrote:
>>> I thought this was simply going to be an SMTP like service that any SMTP
>>> client could utilize, keeping the BURL/URLAUTH pieces working only
>>> between Dovecot and the MTA it works with. Meaning, instead of
>>> connecting an SMTP service provided by Postfix, you connect to one
>>> provided by Dovecot. I guess there is a good reason it couldn't be made
>>> to work this way.
>>>
>>> For obvious reasons, the likelihood that Thunderbird will add
>>> BURL/URLAUTH support anytime in the next few years is probably nonexistent.
> 
>> Actually it's supposed to serve as SMTP-like service as well.
> 
> Meaning... it actually won't require Thunderbird to implement anything
> (at least painful) to allow it to make use of it?
> 
> 
> 
> Thanks Aki,
> 
> Charles
> 

Re: New Dovecot service: SMTP Submission (RFC6409)

[Tanstaafl]

On 12/14/2017, 3:03:41 AM, Aki Tuomi  wrote:
> On 13.12.2017 21:41, Tanstaafl wrote:
>> On 12/12/2017, 1:39:08 PM, Stephan Bosch  wrote:
>> I thought this was simply going to be an SMTP like service that any SMTP
>> client could utilize, keeping the BURL/URLAUTH pieces working only
>> between Dovecot and the MTA it works with. Meaning, instead of
>> connecting an SMTP service provided by Postfix, you connect to one
>> provided by Dovecot. I guess there is a good reason it couldn't be made
>> to work this way.
>>
>> For obvious reasons, the likelihood that Thunderbird will add
>> BURL/URLAUTH support anytime in the next few years is probably nonexistent.

> Actually it's supposed to serve as SMTP-like service as well.

Meaning... it actually won't require Thunderbird to implement anything
(at least painful) to allow it to make use of it?



Thanks Aki,

Charles

Re: New Dovecot service: SMTP Submission (RFC6409)

[Tanstaafl]

On 12/12/2017, 1:39:08 PM, Stephan Bosch  wrote:
> However, keep in mind that for this particular feature we're just 
> providing the "chicken" as it were. The "egg", i.e. client support, is 
> still to come. Apart from Trojita (which I think is still not widely 
> used), I know of no IMAP client supporting BURL/URLAUTH for message 
> submission. I'd expect to see it first for clients that can truly 
> benefit; i.e., mobile clients such as K9.

Oh... bummer...

I thought this was simply going to be an SMTP like service that any SMTP
client could utilize, keeping the BURL/URLAUTH pieces working only
between Dovecot and the MTA it works with. Meaning, instead of
connecting an SMTP service provided by Postfix, you connect to one
provided by Dovecot. I guess there is a good reason it couldn't be made
to work this way.

For obvious reasons, the likelihood that Thunderbird will add
BURL/URLAUTH support anytime in the next few years is probably nonexistent.

:(

Re: New Dovecot service: SMTP Submission (RFC6409)

[Tanstaafl]

This is fantastic Stephan! Especially since I'll soon be rolling a new
Dovecot server to act as a backup for our current Office 365 mail, as
well as to be prepared in case I can ever talk the boss into migrating
back to dovecot (we were using Dovecot for a really long time until he
was convinced by others that we 'had' to be on Office 365).

I'll also be setting up a shiny new VPS for my own private mail server,
to provide better service that I currently get from my shared Dreamhost
account.

But can you confirm...

Would this also be called 'BURL' support?

And will this initial implementation work with current Postfix to
provide the basic Save-To-Sent feature?

I seem to recall there was some minor code required on the Postfix side,
and Wietse seemed to not have a problem implementing it, but had asked
about any IMAP Clients supporting BURL...

If this won't work with current versions of Postfix, maybe you or Timo
or someone could go poke him now that Dovecot supports it?

Anyway, thanks again, I'm really looking forward to being able to do
away with the 'Save-To-Sent' wastage.


On 12/11/2017, 6:14:26 PM, Stephan Bosch  wrote:
> Hi,
> 
> As some of you know, I started implementing the SMTP submission proxy a
> few years ago. It acts as a front-end for any MTA, adding the necessary
> functionality for an SMTP submission service, also known as a Mail
> Submission Agent (MSA) (https://tools.ietf.org/html/rfc6409). The main
> reason I created this, back then, was implementing the BURL capability
> (https://tools.ietf.org/html/rfc4468). The main application of that
> capability -- together with IMAP URLAUTH -- is avoiding a duplicate
> upload of submitted e-mail messages; normally the message is both sent
> through SMTP and uploaded to the "Sent" folder through IMAP. Using BURL,
> the client can first upload the message to IMAP and then use BURL to
> make the SMTP server fetch the message from IMAP for submission, thereby
> avoiding a second upload. Apart from BURL, the submission proxy service 
> also adds the required AUTH support, avoiding the need to configure the
> MTA for SASL authentication. More SMTP capabilities like CHUNKING and
> SIZE are supported, without requiring the backend MTA supporting these
> extensions. Other capabilities like DSN currently require support from
> the backend/relay MTA.
> 
> At this point, the submission proxy is still pretty basic. However, it
> will provide a basis for adding all kinds of functionality in the (not
> so distant) future. For the first time, it will be possible to act upon
> message submission, rather than only message retrieval; e.g. plugins can
> be devised that process outgoing messages somehow. Examples of the
> things we could do are adding Sieve filtering support for outgoing
> messages, or implicitly storing submitted messages to the Sent folder.
> Once a plugin API is devised, you can create your own plugins.
> 
> The reason I send this message now, is that this code is finally merged
> into the Dovecot master repository. This means that it is part of the
> upcoming 2.3 release. Now that it is merged, you can install and test it
> from Github if you like. Feedback is of course appreciated. The
> documentation is still pretty sparse, but there is currently not much to
> configure. Just add "submission" to the protocols and configure the
> relay MTA server. The configuration is currently only documented in the
> example configuration in doc/example-config/conf.d/20-submission.conf.
> The submission service is a login service, just like IMAP, POP3 and
> ManageSieve, so clients are required to authenticate. The same
> authentication configuration will also apply to submission, unless
> you're doing protocol-specific things, in which case you may need to
> amend your configuration for the new protocol. BURL support requires a
> working IMAP URLAUTH implementation.
> 
> I've updated the automated Xi Debian package builder to create an
> additional dovecot-submissiond package. So, if you're using the Xi
> packages, you only need to install that package and configure the relay MTA.

Re: dovecot-lda without starting dovecot?

[Tanstaafl]

On 11/6/2017, 6:18:43 PM, Stephan von Krawczynski 
wrote:
> On Mon, 6 Nov 2017 09:50:16 -0500 Tanstaafl  wrote:
>> Dovecot's indexing is one of its main features, and WHY it is so much
>> faster than others.
>>
>> And you want to just turn it off? Good luck...

> It seems you have not understood what I am talking about. Our pre-dovecot lda
> did not touch the index either. And it did not harm the imap/pop procedure in
> any way. So we know there is no need to fiddle with the index in the process
> of delivery into the maildirs to keep our performance as it was before.

Apparently I'm still missing something...

Sure, you may be keeping your performance at pre-dovecot levels - but
why on earth would that even be a goal?

One of the main reasons I switched from Courier to Dovecot a very long
time ago was for the expected performance boost from the use of the
indexes, which were automatically updated at delivery time (if you used
the LDA), and the boost was huge, I was extremely pleased with the results.

There is no 'fiddling', it just works.

Re: dovecot-lda without starting dovecot?

[Tanstaafl]

On 11/6/2017, 4:01:19 AM, Stephan von Krawczynski 
wrote:
> Still we are not content with it touching/locking dovecot.index.log. If
> someone pointed at one location in the code where this could be disabled we
> would implement a new param for switching that off.

?

Dovecot's indexing is one of its main features, and WHY it is so much
faster than others.

And you want to just turn it off? Good luck...

Re: Dovecot - Postfix Calender Synchronisation

[Tanstaafl]

On Wed Aug 23 2017 14:26:15 GMT-0400 (Eastern Standard Time), Rupert
Gallagher  wrote:
> On Wed, Aug 23, 2017 at 7:22 PM, Tanstaafl  wrote:
> 
>> I would have to put in a plug for SOGo - very lightweight, ...
> 
>> Care to elaborate?
> 
> https://github.com/inverse-inc/sogo/blob/master/Documentation/SOGoInstallationGuide.asciidoc#system-requirements
> 
> Too many requirements.

I obviously meant would you care to elaborate on this comment of yours:

"There are two portable file formats for calendar and contacts that work
across applications and systems, but no server that can use them, and
use them safely."

Any client<>server system will have some basic requirements. SOGo is
very easy to install (as long as you are using a repo+package manager,
and aren't trying to install each dependency manually by hand).

Re: Dovecot - Postfix Calender Synchronisation

[Tanstaafl]

On Wed Aug 23 2017 08:57:27 GMT-0400 (Eastern Standard Time), Sebastian
Arcus  wrote:
> On 23/08/17 09:11, m...@caloro.ch wrote:
>> On Wed Aug 23 2017 12:07:03 GMT-0400 (Eastern Standard Time),
>> Rupert Gallagher  wrote:
>>> Please witch add-on possibilities exist to synchronize the Calednar with
>>> Dovecot and Postfix.
>>>
>>> Can give me here any a possible direction ?

>> A shout here for Horde. I have installed and configured over the
>> years several instances of Horde with Dovecot, Exim and Postgresql
>> (but it should work equally well with Postfix). I too have
>> evaluated a few years ago the various options available and Horde
>> was the only one at the time which scaled well, was flexible enough
>> and met various other criteria I had on my list.

I would have to put in a plug for SOGo - very lightweight, fairly simple
to install and configure, and works extremely well with Thunderbird as
well as newer versions of Outlook (2013+).

> I still find impediments to the adoption of any of those "solutions".
> Too many software dependencies, like PHP, DB, python, and a virtual
> machine. --- There are two portable file formats for calendar and 
> contacts that work across applications and systems, but no server
> that can use them, and use the safely.
Care to elaborate?

Re: Ubuntu 16.04 dovecot-core requires deprecated ntpdate

[Tanstaafl]

On 8/17/2017, 9:57:32 AM, Michael Fox  wrote:
> When I select the dovecot-core package in Synaptic, it also wants to install
> ntpdate.
> 
> Problem:  ntpdate has been replaced in Ubuntu with timedatectl.  In fact, if
> ntpdate exists on the machine, ntpd will not work properly.

So, this is obviously an Ubuntu packaging problem, so should be reported
there.

Re: correct permissions /etc/dovecot ?

[Tanstaafl]

On Wed Aug 16 2017 02:57:32 GMT-0400 (Eastern Standard Time),
voy...@sbt.net.au  wrote:
> what permissions/ownership should /etc/dovecot/files have?

It would be nice if Dovecot had something like Postfix's set-permissions
command.

Re: under another kind of attack

[Tanstaafl]

On Sat Jul 29 2017 13:44:53 GMT-0400 (Eastern Standard Time), Doug
Barton  wrote:
> On 07/25/2017 07:54 AM, mj wrote:
>> Since we implemented country blocking,
> 
> Please don't do that. Balkanizing the Internet doesn't really benefit 
> anyone, and makes innovation a lot more difficult.

Your use of the term 'balkanizing' is in reality an attempt to balkanize
this list/thread.

In reality, when you (the sysadmin) know with absolutely certainty that
no one from certain countries should ever be logging into one or more
servers/services you provide, outright blocking based on those country's
is not only a good idea, it is common sense.

In our case - all of our email users are in the USA, and virtually never
travel outside the USA. Why then should I leave our mail servers open to
people in Russia, China, Saudi Arabia, etc, when we have no users there?

This does not create a contentious situation for anyone other than
hackers from foreign countries trying to access our systems - unless you
think that hackers attempting to hack into systems they have no right to
access have some kind of 'right' nevertheless to be able to try, thus
have a legitimate 'compliant' about me blocking their entire country.

This is not a 'security through obscurity' argument. Geo-blocking can
dramatically reduce the risk to systems that, again, have no legitimate
users in said countries, and improve the signal-to-noise ratio of logs
as well.

> Instead, take a look at the fail2ban scenarios in this thread, which 
> solve the actual problem with a precision tool, instead of a hammer.

Fail2ban doesn't work against distributed attacks that use a different
IP address each time.

While I agree that the combination of methods being discussed in  this
thread are valuable, their use, in combination with outright blocking
entire swaths of sources of attacks, is an an even better way to protect
ones systems.

Of course, the above doesn't and cannot apply to servers/services that
*do* deal with users from all over the world.

As well, if you don't have users who need to be able to log in from many
foreign countries, you are free to disagree and leave your systems
unnecessarily open to such attacks if you like, but that doesn't mean
you get to attack others with impunity who recognize the sanity of such
measures under appropriate circumstances.

Re: under some kind of attack

[Tanstaafl]

Welcome to the world of mail admin...

On 7/18/2017, 3:44:20 PM, mj  wrote:
> Hi all,
> 
> It seems we are under some kind of password guessing attack:
> 
>> Jul 18 21:33:33 auth: Info: ldap(username1,103.6.223.61,): 
>> invalid credentials (given password: 1q2w3e4r5t)
>> Jul 18 21:34:16 auth: Info: ldap(username1,221.4.61.180,<89WnmZxUrADdBD20>): 
>> invalid credentials (given password: 1q2w3e4r5t)
>> Jul 18 21:36:13 auth: Info: 
>> ldap(username2,117.243.180.225,): invalid credentials 
>> (given password: 1q2w3e4r)
>> Jul 18 21:36:50 auth: Info: 
>> ldap(username2,58.59.103.230,): invalid credentials (given 
>> password: 1q2w3e4r)
>> Jul 18 21:36:56 auth: Info: 
>> ldap(username4,58.215.13.154,): invalid credentials (given 
>> password: 1q2w3e4r5t)
>> Jul 18 21:37:18 auth: Info: 
>> ldap(username3,220.175.154.205,): invalid credentials 
>> (given password: 1q2w3e4r)
>> Jul 18 21:37:25 auth: Info: 
>> ldap(username5,14.142.29.142,<40zopJxUSgAOjh2O>): invalid credentials (given 
>> password: 1q2w3e4r)
>> Jul 18 21:37:27 auth: Info: ldap(username4,119.1.98.121,): 
>> invalid credentials (given password: 1q2w3e4r5t)
>> Jul 18 21:37:54 auth: Info: 
>> ldap(username3,218.76.156.11,): invalid credentials (given 
>> password: 1q2w3e4r)
> 
> Different IPs, different usernames, but all (almost) the same password.
> 
> Any idea what we can do about this??
> 
> Any advice you could give us would be very much appreciated.
> 
> MJ
> 

Re: migrate Maildir to mdbox

[Tanstaafl]

On Tue May 02 2017 10:58:33 GMT-0400 (Eastern Standard Time), Aki Tuomi
 wrote:
> mbox is not recommended for new setups unless you have very good reason to do 
> so. 
> 
> Use maildir or sdbox.


Just curious - why not mdbox?

Re: Replacement for antispam plugin

[Tanstaafl]

On Wed Mar 01 2017 03:11:48 GMT-0500 (Eastern Standard Time), Aki Tuomi
 wrote:
>> But, if the imapsieve is only matching to literal foldernames, should
>> I just duplicate the trigger lines for each type of junk folder or is
>> there a method to have the sieve script enumerate all the options
>> listed by 'special use'  or is there a better method for this? I want
>> to put the spam-mail-filing script as a global sieve script as all
>> users will need it, rather than duplicating out for each user.
>>
> There is no way to match special use folders at the moment, but I like
> the idea.

If by 'match' you mean, basically, a way to define aliases for different
special use folders to a single mailbox name, I suggested this a long
time ago, and love the idea.

Hopefully you'll at least add this to your official 'ToDo' (or 'maybe
ToDo' list?

:) Thanks

Re: Scaling to 10 Million IMAP sessions on a single server

[Tanstaafl]

On 2/22/2017, 3:46:08 PM, KT Walrus  wrote:
> I want to use mdbox format but I have heard that these index files do
> get corrupted occasionally and have to be rebuilt (possibly using an
> older version of the index file to construct a new one). I worry that
> using mdbox might cause my users to see the IMAP flags suddenly reset
> back to a previous state (like seeing previously read messages
> becoming unread in their mail clients).

This is the only reason I haven't moved to mdbox myself. I really,
really wish there was a way to not have to worry about losing flags.

Re: Director+NFS Experiences

[Tanstaafl]

On Fri Feb 24 2017 14:41:17 GMT-0500 (Eastern Standard Time), Francisco
Wagner C. Freire  wrote:
> In our experience. A ring with more of 4 servers is bad, we have sync
> problems everyone.  Using 4 or less works perfect.

Since this contradicts Timo's recommendation not to use more than 10, it
sounds to me like you either encountered a bug, or possibly it was not
optimally deployed.

Did you ever come here and ask for help?

Re: v2.2.28 release candidate released

[Tanstaafl]

On Mon Feb 20 2017 05:15:34 GMT-0500 (Eastern Standard Time), Timo
Sirainen  wrote:
>  + auth: Support OAUTHBEARER and XOAUTH2 mechanisms. Also support them
>in lib-dsasl for client side.

So... does this mean dovecot now has OAUTH2 support? If so... yay! and
I'll go open a Thunderbird bug to add support for dovecot's OAUTH2...

Re: JMAP support in Dovecot

[Tanstaafl]

Hi Aki,

Someone just asked in the bug for Thunderbird for this, so...

Is there a git branch that they could use to start playing with what is
there? If not, any idea when that might happen?

It sounds like someone following the Thunderbird bug is interested in
working on this, but they obviously need something to test against.

Thanks,

Charles


On 11/27/2016 5:28 AM, Aki Tuomi  wrote:
> Hi!
> 
> We are working on including JMAP support to Dovecot. At this moment I cannot 
> give any promise for exact version, but hopefully it will be part of v2.3
> 
> Aki Tuomi
> 
> Dovecot Oy
> 
>> On November 26, 2016 at 11:17 PM Andrew Jones  wrote:
>>
>>
>> Hi Marcus
>>
>> Thanks for your helpful reply.
>>
>> Do you know what is going on with JMAP development into Dovecot 2.5?
>>
>> It's difficult to get any sort of information from the roadmap and there are 
>> no Dovecot forums.
>>
>> One of the main reasons I'm interested in JMAP is because of Roundcube Next 
>> and also the other clients it will power. Sadly, there has been little going 
>> on and having emailed Thomas, he is no longer involved in Roundcube Next - 
>> which is a shame. The Kolab guys are really taking liberties here, and 
>> trying their product, the thing is littered with bugs everywhere.
>>
>> Are you able to comment on what is going on with JMAP development into 
>> Dovecot?
>>
>> Thanks 
>>
>> Andrew 
>>
>>
>>
>>
>> Sent from my iPhone
>>
>>> On 26 Nov 2016, at 19:16, Marcus Rueckert  wrote:
>>>
 On 2016-11-26 11:07:00 -0800, WJCarpenter wrote:
 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.)
>>>
>>> roundcube-next builds on top of it.
>>>
>>>darix
>>>
>>> -- 
>>>   openSUSE - SUSE Linux is my linux
>>>   openSUSE is good for you
>>>   www.opensuse.org

Re: mailboxes and capitalisation

[Tanstaafl]

On 12/13/2016 4:48 AM, Thorsten Hater  wrote:
> I have set up a series of special-use mailboxes in the default namespace
> differing by capitalisation of the names, mainly to capture multiple
> mailboxes
> with autoexpunge
> 
> namespace inbox {
>   ...
>   mailbox Trash {
> auto= no
> autoexpunge = 30d
> special_use = \Trash
>   }
>   mailbox trash {
> auto= no
> autoexpunge = 30d
> special_use = \Trash
>   }

Ugh... why create such a huge pain point for yourself?

I would never allow case sensitivity for usernames, or mail storage.
Makes no sense.

Re: Good email client to use with Dovecot?

[Tanstaafl]

On 11/22/2016 11:05 AM, Larry Rosenman  wrote:
> I keep a separate ARCHIVE/-MM/ namespace for old mail and move
> the mail on the first of the month.  That way most clients don't load it,
> but I can get to them.  I keep one box per mailing list and other "things".

I keep a single 'Old Mail' folder, where I file anything that I want to
keep but doesn't fit into any of my 20 or 30 specific folders I've created.

> So, yes, I can see multi-hundreds of folders.

Again, I can't, it is much easier, in my opinion, to only have to search
a single folder, rather than try to figure out which folder something is
more likely to be in - but whatever works for you...

Re: Good email client to use with Dovecot?

[Tanstaafl]

On 11/22/2016 10:35 AM, @lbutlr  wrote:
> On Nov 22, 2016, at 7:48 AM, Tanstaafl  wrote:
>> I'm trying for the life of me to see a use case for anywhere close to
>> 1,000 folders, and am failing. That would be a major problem just from
>> the human side. How do you find anything?

> I can see it, though I think it’s excessive.
> 
> List Mail
>Dovecot
>  2011-06
>  2011-07
>  2011-08



Like I said, I simply don't see it. There is simply zero reason to split
things up like this. It is trivial to limit your view to just what you
want with filters or just plain sorting (by date in this case).

Just not enough bang for the buck. Again, this is jut my opinion, if
this makes someone else feel better/more organized or whatever,
obviously they are free to have as many folders as they want.

Re: Good email client to use with Dovecot?

[Tanstaafl]

On 11/18/2016 1:50 PM, Steve Litt  wrote:
> On Fri, 18 Nov 2016 08:14:02 -0500
> Tanstaafl  wrote:
>> On 11/17/2016 10:58 AM, Steve Litt  wrote:
>>> I have over 620K emails in over 1000 folders. This turns Thunderbird
>>> into an all day affair, just to refresh its caches.  
>>
>> There are lots of knobs you can tweak to improve the situation, but
>> the bottom line is - 1,000 folders (really?!?), 650,000 emails -
>> well... this is going to be a problem for almost any client.

> It wasn't a problem for Kmail, before the disastrous conversion to
> Kmail2. It wasn't a problem with Claws-Mail (I'm leaving Claws for
> non-technical reasons).

Let me clarify - I have no way of knowing if Thunderbird would choke due
to the incredibly large number of folders. The number of emails is much
less the problem.

I have maybe 50 folders, and maybe 200,000 total emails, and don't have
any performance issues, unless (and even then they are minor and
temporary) I'm setting up a new/fresh profile (takes a while for header
downloads), or repairing a folder with a lot of messages.

I'm trying for the life of me to see a use case for anywhere close to
1,000 folders, and am failing. That would be a major problem just from
the human side. How do you find anything?

But, to each their own, you must have a way of dealing with it that
suits you.

Re: Good email client to use with Dovecot?

[Tanstaafl]

On 11/17/2016 11:03 PM, li...@lazygranch.com  wrote:
> Comments about the retired TB:
> ‎https://blog.mozilla.org/thunderbird/
> 
> Practically what this means is that in 2016, Thunderbird will finally
> be able to accept donations from users directed toward the update and
> maintenance of Thunderbird. In the long run, Thunderbird needs to
> rely on our users for support, and not expect to be subsidized by
> revenue from Firefox. We welcome this help from the Mozilla
> Foundation in moving toward our goal of developing independent
> sources of income for Thunderbird.

The interesting thing is that Thunderbird has seen a lot more bug fixes
and improvements since Mozilla 'abandoned' development of it than it
ever saw under direct Mozilla 'care'.

There are some uncomfortable pain points coming up (deprecation of
XUL/XPCOM being the main ones), but I'm confident Thunderbird will
emerge victorious, once again.

:)

Re: Good email client to use with Dovecot?

[Tanstaafl]

On 11/17/2016 10:58 AM, Steve Litt  wrote:
> I have over 620K emails in over 1000 folders. This turns Thunderbird
> into an all day affair, just to refresh its caches.

There are lots of knobs you can tweak to improve the situation, but the
bottom line is - 1,000 folders (really?!?), 650,000 emails - well...
this is going to be a problem for almost any client.

Re: New Gmail Android App and Dovecot

[Tanstaafl]

On 11/16/2016 2:39 PM, David Flanigan  wrote:
> Dovecot: v2.2.10 (using self signed certificates)

Very old. First thing on your agenda should be top upgrade...

Re: Server migration

[Tanstaafl]

On 11/1/2016 3:58 AM, Sami Ketola  wrote:
> On 31 Oct 2016, at 13.11, Tanstaafl  wrote:
>> Ok, interesting. So... how does dsync do it? Or would it only work
>> between two dovecot servers?
>>
>> I'm interested in migrating from other servers (Office 365 in one case).

> Dsync does not use IMAP protocol to store the mails to storage but instead 
> uses the 
> dovecot storage API to do that. Internally we can set what ever properties we 
> want to
> including IMAP UIDs and POP3 UIDLs. 
> 
> Migrating from legacy system should then be done by pulling the mails from the
> legacy platform by using the imapc connector and storing them by using the 
> internal apis.
> 
> We can also store mails to imapc: location but in that case there is many 
> properties that
> will be lost due to limitations of the IMAP protocol.

Thanks Sami, but I don't see a definitive answer top my question in the
above...

So, when migrating from legacy system (legacy = non-dovecot) using
imapc, is dovecot able to preserver the UIDs?

Thanks, and my apologies for being a bit dense...

Re: Server migration

[Tanstaafl]

On 10/30/2016 5:32 AM, Sami Ketola  wrote:
> On 28 Oct 2016, at 16.54, Tanstaafl  wrote:
>> Oh... I thought the --useuid option eliminated this problem?
>>
>> https://imapsync.lamiral.info/FAQ.d/FAQ.Duplicates.txt

> It does not. There is no option at IMAP level to set the UID.
> 
> In this case —useuid seems to keep track on source:uid -> dest:uid
> pairs on multiple syncs and uses uid numbers to avoid syncing mails
> as duplicates instead of using headers to do that.

Ok, interesting. So... how does dsync do it? Or would it only work
between two dovecot servers?

I'm interested in migrating from other servers (Office 365 in one case).

Thanks,

Charles

Re: Server migration

[Tanstaafl]

On 10/27/2016 8:36 AM, Timo Sirainen  wrote:
> On 27 Oct 2016, at 15:29, Tanstaafl  wrote:
>> On 10/26/2016 2:38 AM, Gandalf Corvotempesta
>>> my only question is: how to manage the email received on the new server
>>> during the last rsync phase?
>>
>> Use IMAPSync - much better than rsync for this.

> imapsync will change IMAP UIDs and cause clients to redownload all
> mails. http://wiki2.dovecot.org/Migration/Dsync should work though.

Oh... I thought the --useuid option eliminated this problem?

https://imapsync.lamiral.info/FAQ.d/FAQ.Duplicates.txt

Re: Server migration

[Tanstaafl]

On 10/26/2016 2:38 AM, Gandalf Corvotempesta
 wrote:
> This is much easier than dovecot replication as i can start immedialy with
> no need to upgrade the old server
> 
> my only question is: how to manage the email received on the new server
> during the last rsync phase?

Use IMAPSync - much better than rsync for this.

Re: Supporting RFC 5466 (IMAP4 Extension for Named Searches (Filters))

[Tanstaafl]

On 9/26/2016 11:51 AM, Aki Tuomi  wrote:
> 
>> On September 26, 2016 at 4:14 PM Tanstaafl  wrote:
>>
>>
>> On 9/19/2016 11:26 AM, Tanstaafl  wrote:
>>> On 10/1/2014 3:21 PM, Stephan Bosch  wrote:
>>>> On 10/1/2014 2:42 PM, Jesus Cea wrote:
>>>>> I wonder if Dovecot  supports RFC 5466 (IMAP4 Extension for Named
>>>>> Searches (Filters)) or if there is any plan about it.
>>>
>>>> I have a partial implementation in my patch queue. I haven't worked on
>>>> it for a few months now due to other projects that took precedence. It
>>>> still may take quite a while until I can continue that effort.
>>>
>>> I don't know if it is a good idea to resurrect such an old thread, but...
>>>
>>> Any chance there has been movement on this?
>>>
>>> There is a Thunderbird bug opened for supporting this:
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=439047
>>>
>>> and it would be much easier to try to push it forward if there was
>>> actually a server that supported it already.
>>
>> Timo? Aki? Anyone?
> 
> Hi! 
> 
> We need to discuss this internally

Ok, thanks... hope something will come of it... :)

Re: Supporting RFC 5466 (IMAP4 Extension for Named Searches (Filters))

[Tanstaafl]

On 9/19/2016 11:26 AM, Tanstaafl  wrote:
> On 10/1/2014 3:21 PM, Stephan Bosch  wrote:
>> On 10/1/2014 2:42 PM, Jesus Cea wrote:
>>> I wonder if Dovecot  supports RFC 5466 (IMAP4 Extension for Named
>>> Searches (Filters)) or if there is any plan about it.
> 
>> I have a partial implementation in my patch queue. I haven't worked on
>> it for a few months now due to other projects that took precedence. It
>> still may take quite a while until I can continue that effort.
> 
> I don't know if it is a good idea to resurrect such an old thread, but...
> 
> Any chance there has been movement on this?
> 
> There is a Thunderbird bug opened for supporting this:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=439047
> 
> and it would be much easier to try to push it forward if there was
> actually a server that supported it already.

Timo? Aki? Anyone?

Re: Panic: file auth-request.c

[Tanstaafl]

On 9/17/2016 2:15 PM, Chris Wik  wrote:
> So we upgraded to a new CentOS 7 server with SSD RAID, fast CPUs and
> tons of RAM. No more load problems. We compiled the latest dovecot
> from source (as the version from CentOS yum repo is already quite
> old, figure we might as well run the latest version since we were
> upgrading anyway).

Then on 9/18/2016 6:50 AM, Chris Wik  wrote:
> In my local source of 2.2.5,

???

Latest dovecot version is 2.2.25 - or was that (hopefully) a typo?

http://www.dovecot.org/download.html

Re: Supporting RFC 5466 (IMAP4 Extension for Named Searches (Filters))

[Tanstaafl]

On 10/1/2014 3:21 PM, Stephan Bosch  wrote:
> On 10/1/2014 2:42 PM, Jesus Cea wrote:
>> I wonder if Dovecot  supports RFC 5466 (IMAP4 Extension for Named
>> Searches (Filters)) or if there is any plan about it.

> I have a partial implementation in my patch queue. I haven't worked on
> it for a few months now due to other projects that took precedence. It
> still may take quite a while until I can continue that effort.

I don't know if it is a good idea to resurrect such an old thread, but...

Any chance there has been movement on this?

There is a Thunderbird bug opened for supporting this:

https://bugzilla.mozilla.org/show_bug.cgi?id=439047

and it would be much easier to try to push it forward if there was
actually a server that supported it already.

Thanks

Re: Bug: Shared Mailbox - Case Sensitivity

[Tanstaafl]

On 9/16/2016 6:53 AM, Aki Tuomi  wrote:
> On 16.09.2016 12:54, Leander Schäfer wrote:
>> user=Leander@MyDomain.LocalDomain eilrwts
>> ^^ Doesn't work

> Hi! Did you know you can use %Lu instead of %u to force lowercasing?

In my opinion this should be the default...

Re: dovecot-keywords and mbox

[Tanstaafl]

On 9/15/2016 1:59 PM, Anton Yuzhaninov  wrote:
> With Maildir++ it is possible to store list of IMAP message keyworkds 
> (tags in Thunderbird) on server in dovecot-keywords file.
> 
> Is it possible the same with mbox mailboxes?
> 
> My mbox directory contains .subscriptions file, but no .dovecot-keywords 
> file.

They are stored directly in the mbox file(s):

http://wiki2.dovecot.org/MailboxFormat/mbox#Dovecot.27s_Metadata

Re: virtual users, mailer daemon send mails to non existant recipient and dovecot store it

[Tanstaafl]

On 8/24/2016 8:08 AM, Tanstaafl  wrote:
> 2. Don't accept mail from domains that you control that don't originate
> from your smtp server(s)
> 
> Problem solved.

Oops, that should of course read:

2. Don't accept mail that is both TO & FROM a (the same) domain that you
control that doesn't originate from your SMTP server(s)

Re: Sub addressing delimiters

[Tanstaafl]

On 8/23/2016 4:42 PM, Kurt Fitzner  wrote:
> There is a disconnect between the way Postfix handles 
> recipient_delimiter and the way Dovecot handles it.  For Postfix, it is 
> a set of delimiters that can each individually be used to separate the 
> address from the .  In Dovecot, having multiple characters in 
> recipient_delimiters simply makes it a multi-character single delimiter.
> 
> For my purposes, the Postfix method is much more versatile.  Extra 
> delimiters can be added without breaking the way users currently have 
> delimiters.

Objection: assumes facts not in evidence.

This is the way it is supposed to work now in dovecot, so, either it is
now broken, was always broken (I haven't had an opportunity to test it
since I was forced to migrate our email server to Office365 last year),
or you are not doing it right.

But we'd need to see your config to make that determination...

Re: virtual users, mailer daemon send mails to non existant recipient and dovecot store it

[Tanstaafl]

On 8/23/2016 11:57 AM, Sam  wrote:
> The problem is that the sender of the spam as something like 
> voicem...@ourdomain.fr ( the user voicemail doesn't exist in our database )
> 
> And sometimes dovecot create the directory and store the reply 's mail...

1. Don't accept mail for non-existent (invalid) users

2. Don't accept mail from domains that you control that don't originate
from your smtp server(s)

Problem solved.

Re: an e-mail client for dovecot ?

[Tanstaafl]

Please do NOT send to me directly, I am on the list.

Anyone who wishes direct responses should say so by setting explicit
Reply-To.

On 7/19/2016 11:42 AM, Miquel van Smoorenburg  wrote:
> On 18/07/16 11:46, Stephan Bosch wrote:
>>
>>
>> Op 16-7-2016 om 18:12 schreef Charles Marcus:
>>>
>>> On July 16, 2016 4:02:33 AM EDT, Spyros Tsiolis 
>>> wrote:
 Since I have quite some experiece with thunderbird, I know most of
 its shortcomings
>>> Care to elaborate? Thunderbird is far from perfect, but is by far the
>>> best IMAP client available.
>>>
>>> Most times you can work around supposed short comings (if what you
>>> think are short comings actually are, often they are not)...
>>
>> I agree. I haven't seen anything better so far. Still, with my 100+
>> folders it regularly hangs for a few seconds while it is presumably
>> doing stuff in the background. So, for example composing a message is
>> often a frustrating activity. This is enough reason for me to look for
>> an alternative client, but there is no real alternative...
> 
> Known problem. Sort of a indexing thundering herd problem.
> 
> Preferences -> Advanced -> Config Editor, set  mail.db.idlelimit to a
> large number. I set it to 3000. Fixed it for me..
> 
> Mike.
> 

Re: Migrate Dovecot email archive

[Tanstaafl]

On 6/20/2016 3:13 AM, Steffen Kaiser  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sun, 19 Jun 2016, Marco Usai wrote:
> 
>> Yesterday I'vemigrated Dovecot mail archive between two servers using the 
>> procedure below:
>> 1) Createon the new server the same email accounts existing on the old 
>> server.
>> 2) Transferthe "tarred" mail folder from the old to the new server.
>> For testingpurposes, on Outlook 2007 I've deleted a .pst cache file, forcing 
>> the client todownload all emails again.
>>
>> The switchwas absolutely transparent without any problem. All the emails 
>> were availableand Outlook 2007 noticed no changes.
>> Can Iconsider this a correct procedure or should I use some tools like Dsync 
>> ?

> If you do not change the mail storage format (Maildir -> dbox, or 
> something like that), do not change 32bit -> 64bit, big / little endian 
> a.s.o.
> 
> and if you make sure the old mailbox is not accessed, while you copy the 
> data over,
> 
> it should work :-)
> 
> In fact, I use "rsync".

Imapsync is easier. Made migration from dovecot to Office 365, then
back to dovecot painless and easy, and can be done while both systems
are live.

Re: Mail dates

[Tanstaafl]

On 6/17/2016 1:51 PM, @lbutlr  wrote:
> The issue is that the files currently in the milder have the correct
> time stamps, but Dovecot reports them to the IMAP clients as having a
> different time and date.

Maybe - or maybe not...

Different clients perceive the dates differently...

Here is a decent link to explaining this, as well as providing a tool
that may help you fix the dates:

http://imapsync.lamiral.info/FAQ.d/FAQ.Dates.txt

Re: Mail dates

[Tanstaafl]

On 6/17/2016 1:51 PM, @lbutlr  wrote:
> On Jun 15, 2016, at 10:46 AM, Tanstaafl  wrote:
>> On 6/15/2016 12:30 PM, @lbutlr  wrote:
>>> The original emails were in box files, so that was not the issue.
>>
>> How were they restored?

> The issue is that the files currently in the milder have the correct
> time stamps, but Dovecot reports them to the IMAP clients as having a
> different time and date.

That totally doesn't answer the question.

Again - how were they restored?

Re: Mail dates

[Tanstaafl]

On 6/15/2016 12:30 PM, @lbutlr  wrote:
> On Jun 15, 2016, at 9:44 AM, Tanstaafl  wrote:
>> On 6/14/2016 6:50 PM, @lbutlr  wrote:
>>> Where exactly does dovecot get the date that it reports via IMAP?
>>
>> This is a problem with how you restored the files.
>>
>> On a linux system, you should use something like rsync -a to preserve
>> the original date/times…

> The original emails were in box files, so that was not the issue.

How ere they restored?

Re: Mail dates

[Tanstaafl]

On 6/14/2016 6:50 PM, @lbutlr  wrote:
> Where exactly does dovecot get the date that it reports via IMAP?

This is a problem with how you restored the files.

On a linux system, you should use something like rsync -a to preserve
the original date/times...

Re: Multiple recipient delimiter support?

[Tanstaafl]

On 6/6/2016 2:24 AM, Tom Sommer  wrote:
> https://github.com/dovecot/core/commit/972c9172e9e6a0fc6053efb3d2ee9d354b67727f

So, for non programmers, this is you're way of saying yes, the patch was
committed to core code?

Thanks

Re: Multiple recipient delimiter support?

[Tanstaafl]

On 6/2/2016 3:50 PM, Tanstaafl  wrote:
> On 6/2/2016 10:35 AM, Tanstaafl  wrote:
>> Trying to find out if dovecot supports the use of multiple recipient
>> delimiters, as postfix does, but can't find an answer...
> 
> The reason this is important is simple. I've encountered a lot of sites
> that refuse to accept an email with the '+' character in it, but every
> one of them has accepted one with a '-' sign as the delimiter, so I use
> both.

I did find the prior questions asking the same thing, and that there was
a patch (one liner?) - but apparently it was never integrated?

Timo? Any chance of incorporating this?

Here's a link to the message with the patch:

https://www.mail-archive.com/dovecot@dovecot.org/msg65308.html

Re: Multiple recipient delimiter support?

[Tanstaafl]

On 6/2/2016 10:35 AM, Tanstaafl  wrote:
> Trying to find out if dovecot supports the use of multiple recipient
> delimiters, as postfix does, but can't find an answer...

The reason this is important is simple. I've encountered a lot of sites
that refuse to accept an email with the '+' character in it, but every
one of them has accepted one with a '-' sign as the delimiter, so I use
both.

Multiple recipient delimiter support?

[Tanstaafl]

Trying to find out if dovecot supports the use of multiple recipient
delimiters, as postfix does, but can't find an answer...

The wiki only mentions it in two meaningful places (that I can find)...

With respect to postfix:
/wiki.dovecot.org/LDA/Postfix

The above seems to imply that for postfix/LDA all I need to do is define
it in postfix (which supports multiple recipient delimiters).

And with Pigeonhole/Sieve:
wiki.dovecot.org/Pigeonhole/Sieve/Configuration

It seems to be saying that I must also define the same
recipient_delimiters in dovecot config if using LMTP, and also if I want
to use sieve for filtering of mail.

But, the example and text says nothing about the use of multiple
delimiters...

So, is this supported? If so, the wiki should be updated to reflect this...

Re: ot: migrating TB user's email to new laptop

[Tanstaafl]

On 5/25/2016 5:15 AM, Paolo  wrote:
> Start TB on the new laptop
> Close it
> You have created the default folder/settings in the local %appdata% folder
> 
> copy the %appdata%\Thunderbird folder from the old laptop to the new

No need for step 1.

Just copy the folder from %appdata% on old PC to the new PC %appdata%
and you're done.