With reference to
https://lists.sr.ht/~rjarry/aerc-discuss/%3CCXFL382QTGZE.1CQEMUQ17KR5P%40cepl.eu%3E
I would like to ask about possibility of adding aliases. I don’t
think SUSE is the only company (or large organization), where for
many historical reasons people could have multiple identities:
so my most common work email (and let us ignore that I use this
personal email even for all FLOSS-related work, even when on the
company time) is mcepl@suse.com. However, that goes to our
commerical email provider and all emails are sent to our internal
IMAP server, where I am mcepl@suse.cz. And yes, there is also
mcepl@suse.de floating around as well. Not mentioning that I
believe matej.cepl@suse.com exists as well (but I have never used
it).
When I look at one of my invite, I see these lines in the
iCalendar attachment:
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Matej Cepl;X-NUM-GUESTS=0:mailto:mcepl@suse.com
My work account in aerc is under mcepl@suse.cz address.
So, what exactly `:accept` does here? Sends some email somewhere,
or generating a HTTP request somewhere? Where?
So, please, correct if I get it wrong, the `accept` command means:
1. Search whole email whether it has iCalendar attachment
2. Collect all `ATTENDEE;*PARTSTAT=NEEDS-ACTION` lines.
3. Check whether `from` email address of the current account is
in any of these lines.
4. If yes, send a confirmation email somewhere.
If that is so, then the only modification is in the step 3.,
which should be changed to
3a. Check whether any of emails from the set of the `from` email
address and any address in the `aliases` list (just plain
emails, we don’t need to bother with real names and fancy
formatting) is in any of these lines.
and of course the step #4 would be modified to use this found
address, not necessarily the `from` one.
I guess the only configuration change would be adding another key
to the account record looking like this:
aliases = mcepl@suse.com,mcepl@suse.de,matej.cepl@suse.com
Is that correct?
Should I file all this to the new issue at
https://todo.sr.ht/~rjarry/aerc?
Best,
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
In the course of my life, I have seen Frenchmen, Italians,
Russians, etc.; I am even aware, thanks to Montesquieu, that one
can be a Persian. But, as for Man, I declare that I have never
met him in my life. If he exists, I certainly have no knowledge
of him.
-- Joseph de Maistre, Considerations on France, 1797
On Mon 12 Feb 2024 21:06:31, Matěj Cepl wrote:
> I guess the only configuration change would be adding another key
> to the account record looking like this:
>
> aliases = mcepl@suse.com,mcepl@suse.de,matej.cepl@suse.com
>
> Is that correct?
This recently came up already when the address check was made
case-insensitive.
I am not absolutely certain as to what the best solution there would be
as I am not nearly deep enough into the while invite/accept/refuse flow
aside from using it. What I could imagine being something people could
want to do is:
- reply despite the email not matching
- reply from a different account
Having a sort of alias-system seems reasonable, but in all other cases,
I think this should be something done explicitly (so by prompting the
user).
Just my 2¢ though.
(those 2¢ turned into pseudo-code):
if invitation.to == account.address then
return true
elif alias.contains(invitation.to) then
return true
else
return promptAccept(invitation.to)
> Should I file all this to the new issue at
> https://todo.sr.ht/~rjarry/aerc?
--
Moritz Poldrack
https://moritz.sh
> Formatted to fit your screen.