Real name policy? [was: kmail has messed up the email accounts]

[Paul Vixie]

On Tuesday, 2 June 2020 22:07:26 UTC test wrote:
> On Tue, 2020-06-02 at 15:18 +0000, Paul Vixie wrote:
> > ... i've got control+alt+space bound
> > to
> > "toggle offline/online" because i have to do this several times per day
> > to get
> > the akonadi backend to go out and check for new e-mail.
> 
> Doesn't F5 work for you?  ...

no. either it gets a server push, or just entering the folder causes it to 
rescan, or i have to do the offline/online dance to get it to rescan. F5 is 
never a factor, always a no-op. note, this was far worse in the early days of 
akonadi, than it is now. but i still keep control-alt-space bound to toggle 
online/offline, because it's frequent enough that i need a chord for it.

> > my day job has a security officer role. four of us share a pgp key and
> > the
> > ability to send and receive e-mail as security@$domain. this means my
> > mail
> > account has one sending server, one receiving server, and two identities.
> > if i
> > didn't have kmail i'd have to use multiple e-mail accounts. so your
> > word,
> > "bullshit", may not mean what you think it means.
> 
> I shouldn't have been so undifferitiated about it.

i think that's a point of general agreement.

> > also note, everything about kmail and akonadi gets better if you switch
> > from
> > the default database (mysql) to the other one (postgresql).
> 
> Apparently not everyone agrees to that.  I could try it, though.  Can't I
> just use a "normal" (in this case remote) sql server for kmail?

there are config files that control it. so likely, yes. however, akonadi 
really wants to initialize its own database, start its own database server, 
and then connect to it on a socket whose name it controls. you'll be fighting 
headwinds all the way if you want akonadi to store your e-mail metadata in a 
database you operate separately -- but it can certainly be done.

> It might
> be helpful if I could use phpmyadmin and the mysql client to look at its
> database.  The way it is now, it's all hidden and inaccessible.  Perhaps I
> could help with finding and fixing bugs.

it's hidden but not inaccessible. here's me looking at mine:

$ psql -h /tmp/akonadi-vixie.hash -l
List of databases
Name    | Owner | Encoding |   Collate   |    Ctype    | Access privileges
-----------+-------+----------+-------------+-------------+-------------------
akonadi   | vixie | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
postgres  | vixie | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
template0 | vixie | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/vixie         +
  |       |          |             |             | vixie=CTc/vixie
template1 | vixie | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/vixie         +
  |       |          |             |             | vixie=CTc/vixie
(4 rows)

$ psql -h /tmp/akonadi-vixie.hash akonadi
psql (12.2)
Type "help" for help.

akonadi=# \dt
List of relations
Schema |               Name               | Type  | Owner
--------+----------------------------------+-------+-------
public | collectionattributetable         | table | vixie
public | collectionmimetyperelation       | table | vixie
public | collectionpimitemrelation        | table | vixie
public | collectiontable                  | table | vixie
public | flagtable                        | table | vixie
public | mimetypetable                    | table | vixie
public | parttable                        | table | vixie
public | parttypetable                    | table | vixie
public | pimitemflagrelation              | table | vixie
public | pimitemtable                     | table | vixie
public | pimitemtagrelation               | table | vixie
public | relationtable                    | table | vixie
public | relationtypetable                | table | vixie
public | resourcetable                    | table | vixie
public | schemaversiontable               | table | vixie
public | tagattributetable                | table | vixie
public | tagremoteidresourcerelationtable | table | vixie
public | tagtable                         | table | vixie
public | tagtypetable                     | table | vixie
(19 rows)
akonadi=# \q

this information is vital when upgrading to a new major release of pgsql, 
since the -h option accepts a directory even on pg_dump and pg_restore. on 
minor releases of pgsql, there's never data container incompatibility, so this 
is not something i do often.

-- 
Paul