Re: lda to lmtp

[David Myers]

I'm a bit shocked by this

this is the dovecot mailing list ... I do hope that you guys know each
other IRL and are just having friendly jibes at each other (which actually
would make this funny).

otherwise

seriously

trying to start a flame war (or something) on each other  I never
thought I would see that on the this list.

I'm sitting here having a quiet giggle.

On Sun, Jun 13, 2021 at 2:28 PM @lbutlr  wrote:

> On 13 Jun 2021, at 05:17, Benny Pedersen  wrote:
> > i dont reply anymore to you,
>
> Best plan.
>
> --
> 'Never build a dungeon you wouldn't be happy to spend the night in
> yourself,' said the Patrician (...). 'The world would be a
> happier place if more people remembered that.' --Guards! Guards!
>
>

Re: Any RPMs for aarch64 available?

[David Myers]

Ah hA ...


Here is the regular one :

https://centos.pkgs.org/8/centos-appstream-aarch64/dovecot-2.3.8-2.el8_2.2.aarch64.rpm.html

Sid I mention that sprint this on my phone was painful 


On Fri 4 Dec 2020 at 11:01, David Myers  wrote:

> Not sure if this is what you are looking for...
> But the following link has lots of rpms for dovecot aarch64 / arm64.
>
> They do all say [dovecot-devel...[]] so I’m not sure if they are stable
> versions or something else (requirements for development) ??
>
> It’s hard to tell when using my phone as the screen is much too small !
>
> https://pkgs.org/download/dovecot-devel
>
>
> On Fri 4 Dec 2020 at 10:39, David Pottage  wrote:
>
>> On 2020-12-03 21:41, Peter Cooper Jr. wrote:
>> > Hey, I really appreciate Dovecot being available with standard repos
>> > in repo.dovecot.org. I'm currently using the "CentOS 7" one on Amazon
>> > Linux 2 and it works great for x86_64.
>> >
>> > I'm wondering if there are any plans for also providing arm builds
>> > (aarch64) at some point? Or if they're available somewhere else
>> > already? I may play around with compiling things myself, but just
>> > downloading an official package is generally the easier way to go so I
>> > thought it couldn't hurt to ask.
>>
>> It won't help you for CentOS, but the Debian project includes Arm64
>> (AKA aarch64) as one of their standard supported processor architectures
>> and dovecot is one of their many standard supported packages. eg:
>>
>> https://packages.debian.org/stretch/dovecot-core
>>
>> Is Arm64/aarch64 an official supported architecture in CentOS? If so I
>> would
>> look in the standard repositories for dovecot packages. If not then I
>> would
>> suggest that it is not a good idea to use an unsupported Disto/Arch
>> combo
>> unless you are very familiar with building everything from source.
>>
>> --
>> David Pottage
>>
>

Re: Any RPMs for aarch64 available?

[David Myers]

Not sure if this is what you are looking for...
But the following link has lots of rpms for dovecot aarch64 / arm64.

They do all say [dovecot-devel...[]] so I’m not sure if they are stable
versions or something else (requirements for development) ??

It’s hard to tell when using my phone as the screen is much too small !

https://pkgs.org/download/dovecot-devel


On Fri 4 Dec 2020 at 10:39, David Pottage  wrote:

> On 2020-12-03 21:41, Peter Cooper Jr. wrote:
> > Hey, I really appreciate Dovecot being available with standard repos
> > in repo.dovecot.org. I'm currently using the "CentOS 7" one on Amazon
> > Linux 2 and it works great for x86_64.
> >
> > I'm wondering if there are any plans for also providing arm builds
> > (aarch64) at some point? Or if they're available somewhere else
> > already? I may play around with compiling things myself, but just
> > downloading an official package is generally the easier way to go so I
> > thought it couldn't hurt to ask.
>
> It won't help you for CentOS, but the Debian project includes Arm64
> (AKA aarch64) as one of their standard supported processor architectures
> and dovecot is one of their many standard supported packages. eg:
>
> https://packages.debian.org/stretch/dovecot-core
>
> Is Arm64/aarch64 an official supported architecture in CentOS? If so I
> would
> look in the standard repositories for dovecot packages. If not then I
> would
> suggest that it is not a good idea to use an unsupported Disto/Arch
> combo
> unless you are very familiar with building everything from source.
>
> --
> David Pottage
>

Re: Version controlled (git) Maildir generated by Dovecot

[David Myers]

Adam,

Just for completions sake, and in case someone else comes here in the
future;

This is a link to the current (2020 LO 7) wiki page describing the XML
format
<https://help.libreoffice.org/7.0/en-GB/text/shared/00/0021.html?=WRITER=UNIX>
.

However it doesn't mention about being able to save a document directly as
its constituent XML docs ??? so maybe the function has been removed, I have
miss remembered, or I am going mad (I vote for the 4th option ;) ).

David



On Wed, Oct 7, 2020 at 12:31 PM Adam  wrote:

> Hi David,
>
> I've never heard about such feature in LibreOffice. Thank you for letting
> me know.
>
> I don't really see myself using the feature since I'd have to remember it.
> I'm used to store all sort of stuff / binary files in git. My rule of thumb
> is that if the file is bellow 10M, just add/commit it. Is it proper way of
> using git? No. Does it work? Yes ;-).
>
> I think that the difference between us is that I'm used to use git for
> everything and you aren't which means neither you or I are correct ;-).
>
> Kind regards,
> Adam
>
> -- Původní e-mail --
> Od: David Myers 
> Komu: Adam 
> Datum: 7. 10. 2020 10:05:28
> Předmět: Re: Version controlled (git) Maildir generated by Dovecot
> > Hello Adam,
> >
> > thanks for the reply. Sounds fair enough to me. I hadn't thought about
> that last benefit of git. I haven't deleted anything off my pc for years
> ... still got HDD from 15 years ago with 'something' on them ?
> >
> > Sorry this is going to go off topic somewhat  (ok, I've just read it
> again... its gone off topic a lot... again, apologies for that)
> >
> >
> > One more question, if you are using exclusively LibreOffice, I
> understand it
> > has a mode where it will separate the file into its constituent flat,
> text XML
> > files (style, contents, formatting etc), all of which can then be stored
> in git
> > with all the advantages that privides, no binary files needed. Do you
> use this
> > functionality ? I haven't done this so I don't know how it impacts the
> work flow
> > for a user, or how it will integrate into a git workflow, but would be
> > interested to hear a user experience. I just use the inbuilt
> 'versioning' that
> > is available within libreoffice (much better than multiple copies of the
> same
> > file with just a few changes).
> >
> > Hopefully my last set of 'novice questions' ;)
> >
> > thanks in advance.
> >
> > David
> >
> > On Wed, Oct 7, 2020 at 10:41 AM Adam  wrote:
> > Hi David,
> >
> > Please find answers bellow.
> >
> > Kind regards,
> > Adam
> >
> > -- Původní e-mail --
> > Od: David Myers 
> > Komu: Adam , Dovecot Mailing List <
> dovecot@dovecot.org>
> > Datum: 7. 10. 2020 8:44:28
> > Předmět: Re: Version controlled (git) Maildir generated by Dovecot
> > Hello Adam, and the dovecot list
> >
> > > Just a question, I hate to pollute the thread, so feel free to push
> these
> > > questions into a new thread if deemed necessary. So as you can guess
> I'm a bit
> > > of a newb here, so rather obvious questions are about to arrive
> > >
> > > As you are using GIT for your archive (which is a cool idea by the
> way) I'm
> > > sure you are well aware that not all files types play nicely with
> version
> > > control, my question therefore is : How do you plan to handle
> attachments ?
> >
> > I use git for everything including for example LibreOffice / Word
> documents. Git works just fine with binary files. You can't use text tools
> like "git diff" but... it works.
> >
> > > Also, although I appreciate the idea of using git, emails generally
> don't
> > > 'change', but I guess that also depends on how you are storing them
> (single
> > > email with links to previous / next ... etc, or as a single big file
> for each
> > > specific thread). Although this is hitting my limits of understanding
> for how
> > > dovecot works, so I probably need educating on this (a pointer to the
> docs would
> > > be good).
> >
> > As I mentioned in the first e-mail, I configured Dovecot to use Maildir
> format -> each e-mail is a single text file. Mail body + attachment(s) are
> in the same file, attachment(s) are Base64 encoded.
> >
> > > You seem concerned regarding the files that you are ignoring that you
> will need
> > > to 'recreate them', so why not do a complete git add . prior to adding
> them into
> > > the git ignore, then you have an initial sta

Re: Version controlled (git) Maildir generated by Dovecot

[David Myers]

Hello Adam,

thanks for the reply. Sounds fair enough to me. I hadn't thought about that
last benefit of git. I haven't deleted anything off my pc for years ...
still got HDD from 15 years ago with 'something' on them ?

Sorry this is going to go off topic somewhat  (ok, I've just read it
again... its gone off topic a lot... again, apologies for that)

One more question, if you are using exclusively LibreOffice, I understand
it has a mode where it will separate the file into its constituent flat,
text XML files (style, contents, formatting etc), all of which can then be
stored in git with all the advantages that privides, no binary files
needed. Do you use this functionality ? I haven't done this so I don't know
how it impacts the work flow for a user, or how it will integrate into a
git workflow, but would be interested to hear a user experience. I just use
the inbuilt 'versioning' that is available within libreoffice (much better
than multiple copies of the same file with just a few changes).

Hopefully my last set of 'novice questions' ;)

thanks in advance.

David

On Wed, Oct 7, 2020 at 10:41 AM Adam  wrote:

> Hi David,
>
> Please find answers bellow.
>
> Kind regards,
> Adam
>
> -- Původní e-mail --
> Od: David Myers 
> Komu: Adam , Dovecot Mailing List <
> dovecot@dovecot.org>
> Datum: 7. 10. 2020 8:44:28
> Předmět: Re: Version controlled (git) Maildir generated by Dovecot
> Hello Adam, and the dovecot list
>
> > Just a question, I hate to pollute the thread, so feel free to push these
> > questions into a new thread if deemed necessary. So as you can guess I'm
> a bit
> > of a newb here, so rather obvious questions are about to arrive
> >
> > As you are using GIT for your archive (which is a cool idea by the way)
> I'm
> > sure you are well aware that not all files types play nicely with version
> > control, my question therefore is : How do you plan to handle
> attachments ?
>
> I use git for everything including for example LibreOffice / Word
> documents. Git works just fine with binary files. You can't use text tools
> like "git diff" but... it works.
>
> > Also, although I appreciate the idea of using git, emails generally don't
> > 'change', but I guess that also depends on how you are storing them
> (single
> > email with links to previous / next ... etc, or as a single big file for
> each
> > specific thread). Although this is hitting my limits of understanding
> for how
> > dovecot works, so I probably need educating on this (a pointer to the
> docs would
> > be good).
>
> As I mentioned in the first e-mail, I configured Dovecot to use Maildir
> format -> each e-mail is a single text file. Mail body + attachment(s) are
> in the same file, attachment(s) are Base64 encoded.
>
> > You seem concerned regarding the files that you are ignoring that you
> will need
> > to 'recreate them', so why not do a complete git add . prior to adding
> them into
> > the git ignore, then you have an initial state for those files too.
>
> But I don't want to store files that can be regenerated. I don't want to
> backup stuff, that doesn't have information value.
>
> > Final thought, what advantage do you envisage by using git as opposed to
> simply
> > using a filter to select the files over a certain age, and place them
> into a
> > zipped TAR archive ? Although I guess you could eventually zip the git
> archive
> > too, and in the interim it would remain searchable by your users mail
> clients
> > whilt in git.
>
> I like to use git ;-). Tar will work just fine.
>
> In this use case the only real benefit of git is that it never forgets.
> Unless I delete whole .git directory, I can make a mistake, delete some
> e-mails (files), commit changes and rollback. I can't rollback if I delete
> tar archive.
>
> > Thanks in advance, and apologies once again for polluting your question
> with my
> > own.
>
> David
>

Re: Version controlled (git) Maildir generated by Dovecot

[David Myers]

Hello Adam, and the dovecot list

Just a question, I hate to pollute the thread, so feel free to push these
questions into a new thread if deemed necessary. So as you can guess I'm a
bit of a newb here, so rather obvious questions are about to arrive

As you are using GIT for your archive (which is a cool idea by the way) I'm
sure you are well aware that not all files types play nicely with version
control, my question therefore is : How do you plan to handle attachments ?

Also, although I appreciate the idea of using git, emails generally don't
'change', but I guess that also depends on how you are storing them (single
email with links to previous / next ... etc, or as a single big file for
each specific thread). Although this is hitting my limits of understanding
for how dovecot works, so I probably need educating on this (a pointer to
the docs would be good).

You seem concerned regarding the files that you are ignoring that you will
need to 'recreate them', so why not do a complete git add . prior to adding
them into the git ignore, then you have an initial state for those files
too.

Final thought, what advantage do you envisage by using git as opposed to
simply using a filter to select the files over a certain age, and place
them into a zipped TAR archive ? Although I guess you could eventually zip
the git archive too, and in the interim it would remain searchable by your
users mail clients whilt in git.

Thanks in advance, and apologies once again for polluting your question
with my own.

David











On Tue, Oct 6, 2020 at 7:22 PM Adam  wrote:

> Hi Everybody,
>
> I'd like to start archiving e-mails by moving them to a server with
> running Dovecot.
>
> I installed "dovecot-core" and "dovecot-imapd" (version 2.3.4.1) on Debian
> 10.
>
> One of a few configurations I made is to use Maildir:
>
> # grep '^mail_location = ' /etc/dovecot/conf.d/10-mail.conf
> mail_location = maildir:~/Maildir
>
> I successfully moved some e-mails (at this moment it's just a test) to
> subfolders that describe a year of the backup.
>
> I'd like to start using git on the whole Maildir. After going through the
> Maildir directory and subdirectories I realized that Dovecot saves some
> extra files that I might not need to backup (version control).
>
> Based on my understanding and after reading
> https://wiki.dovecot.org/IndexFiles I believe that the only files I need
> to archive are files in "cur/" directory and these files should start with
> Unix time.
>
> So I decided to write a ".gitignore" whitelist that will include only
> files in "cur/" that start with a number:
>
> # cat .gitignore
> ---
> !.gitignore
> !*/
> !/Maildir/cur/[0-9]*
> !/Maildir/*/cur/[0-9]*
> ---
>
> and it's working:
>
> # git add . --dry-run
> ---
> add '.gitignore'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M110302P17113.mail1,S=8066,W=8276:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M134554P17113.mail1,S=8024,W=8234:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M157569P17113.mail1,S=8005,W=8215:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M180965P17113.mail1,S=8021,W=8231:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M205518P17113.mail1,S=8017,W=8227:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M355896P17113.mail1,S=8042,W=8252:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M52133P17113.mail1,S=8053,W=8263:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M555847P17113.mail1,S=8029,W=8239:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M581502P17113.mail1,S=8047,W=8257:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M606379P17113.mail1,S=8044,W=8254:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M628850P17113.mail1,S=8036,W=8246:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M657431P17113.mail1,S=8069,W=8279:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M681265P17113.mail1,S=8039,W=8249:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M706585P17113.mail1,S=8073,W=8283:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M730046P17113.mail1,S=8059,W=8269:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M753487P17113.mail1,S=8034,W=8244:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M776202P17113.mail1,S=8019,W=8229:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M799238P17113.mail1,S=8085,W=8295:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M822106P17113.mail1,S=8081,W=8291:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M844397P17113.mail1,S=8102,W=8312:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M867952P17113.mail1,S=7964,W=8174:2,S'
> add
> 'Maildir/.INBOX.years.2020.family/cur/1601986418.M889882P17113.mail1,S=7992,W=8202:2,S'
> add
> 

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

[David Myers]

Just for information to help anyone else who ends up on this thread for
similar reasons, here are some links to the relevant pages on the mozilla
site.

Moving Thunderbird Data to a new computer

Which has links to the detalsa about thunderbird profiles
, which has details of
backup and restore etc.

Pertinent to this thread is the restoring to a different location

sub section.

@voytek : If you continue to have problems I would strongly recommend
looking at the mozilla help pages, and if neccessary droping a message to
their forums (they are after all the thunderbird experts ;) ), I personally
have found them very helpful.

Hope that helps

David.

On Wed, May 25, 2016 at 2:59 PM, Skippy  wrote:

> That would work well too
>
> However make sure you get to the bottom of the mail not being on the server
> as well
>
> > -Original Message-
> > From: dovecot [mailto:dovecot-boun...@dovecot.org] On Behalf Of Paolo
> > Sent: 25 May 2016 10:16
> > To: voy...@sbt.net.au
> > Cc: Dovecot Mailing List
> > Subject: Re: ot: migrating TB user's email to new laptop
> >
> > On Wed, 25 May 2016, voy...@sbt.net.au wrote:
> >
> > > On Wed, May 25, 2016 4:31 pm, Philip McGaw wrote:
> > >> Did user historically have POP set up?
> > >
> > > Philip, thanks
> > >
> > > no, not for a long time, IMAP/143/StartTLS on old laptop
> > >
> > >> If you still have access to the old laptop set up imap and move the
> > >> emails back.
> > >
> > > yes, I have old laptop here.
> > > sorry, not sure how to, is that inside TBird, or how ? (not very
> > > familiar with TBird...)
> >
> > 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
> >
> > Finished ;-)
> >
> > The new laptop is now exacly as the old (better if TB same version
> > before migration).
> >
> > --
> >
> > Regards,
> >   Paolo
> >
> > 
>

Re: IP drop list

[David Myers]

hi all

I've been reading this thread with interest. As a rather novice programmer.
I'm not being humble here, I really am not very good, I can do stuff, but
it takes a LONG time. My spaghetti code even has meatballs in it !

Not being a great programmer I'm not really able to code something up, but
it occurred to me something could be scripted, are the other posters
suggesting something like the following 

It does use fail2ban, which I understand isn't the ideal solution, but in
brief

extract the IP's from the fail to ban log file (or any other log file if
you so desire).
Use these to push up to the firewall or insert into your dovecot 'if'
statement (which programmatically even I could probably manage ;) )

I understand that this wasn't exactly what the OP was looking for but
creating the 'if' on the fly, as it were , is certainly better than putting
the values in manually .

An outline for the first part, extracting the ips from a log file, if
anyone is interested can be found here.

http://www.the-art-of-web.com/system/fail2ban-log/

The second bit, adding in the values to the if statement, shouldn't be that
hard... I could probably push something out in Java (but that would
obviously not be any good for anyone!), maybe even PERL it would take me
longer, at a push even a bash script... (I feel like my hair is going grey
;) ...

Maybe even a good bash project for me as a beginner.

Just a question to see if I am understanding the general preposition of
this thread.

thanks for you time, and to helping me to learn this stuff.

David


On 4 Mar 2015 05:04, Earl Killian dove...@lists.killian.com wrote:

 On 2015/3/2 10:03, Reindl Harald wrote:


 that is all nice

 but the main benefit of RBL's is always ignored:

 * centralized
 * no log parsing at all
 * honeypot data are delivered to any host
 * it's cheap
 * it's easy to maintain
 * it don't need any root privileges anywhere

 we have a small honeypot network with a couple of ipranges detecting mass
 port-scans and so on and this data are available *everywhere*

 so if some IP hits there it takes 60 seconds and any service supportings
 DNS blacklists can block them *even before* the bot hits the real
 mailserver at all

  I would like to reiterate Reindl Harald's point above, since subsequent
 discussion has gotten away from it. If Dovecot had DNS RBL support similar
 to Postfix, I think quite a few people would use it, and thereby defeat the
 scanners far more effectively than any other method. It is good that other
 people are suggesting things that will work today, but in terms of what new
 feature would be the best solution, I can't think of one better than a DNS
 RBL.

Re: how to solve : Dovecot version mismatch: Master is v2.1.7, lmtp is v2.2.13

[David Myers]

@Reindl.

I copied my conf.d folder as I deleted all the dovecot files in etc/dovecot
use/etc/dovecot etc ... ...

When I installed the new 2.2.13 version it didn't seem to want to put the
lmtp executable into the location that dovecot was expecting ? So I found
the file and copied it to where it was expected to be.

I then copied my old (backed up) conf.d bact to etc/dovecot/conf.d/
Performed a restart of dovecot, and got the above error.

Quite simple really. But where else does dovecot store files, so as I can
get all the errant files.

David.
On 22 Sep 2014 12:37, Reindl Harald h.rei...@thelounge.net wrote:


 Am 22.09.2014 um 12:32 schrieb Dave Myers:
  Hello again dovecot list ;)
 
  I've recently upgraded my dovecot version from 2.1.7 to 2.2.13.
  both versions where installed from source.
 
  I upgraded why attempting to get lmtp working. I ultimately just coped
 the executable lmtp to the location that
  dovecot was expecting it to be in. but then the above error appeared.

 why do you copy files around?

 if you update a software then make it complete and not
 copy random files around - installing from source would
 in general be better done by build packages because
 they care about obsoleted files and so on

  However when I get the info from dovecot I get the following...
 
  $ dovecot -n
  # 2.2.13: /usr/local/etc/dovecot/dovecot.conf
 
  so there seems to be an issue somewhere.
 
  I should note that I had copied my previous /conf.d/ files and then
 copied them back after the update.
 
  I guess that I have missed a switch during the build, or need to modify
 a line in the config somewhere that tells
  what the version is, but that doesn't explain why the dovecot -n returns
 the correct info, but the error reports
  something different.
 
  I am considering inserting the
   version_ignore=yes
  config option, but where should I insert it?

 no, you should make sure that you have only one version installed
 on your system and no old craft staying around