Attachment flag and signatures

[Yuri D'Elia]

I'm sadly a victim of outlook users who have an inline image in the
signature. I think I've lost the war on their front, so I'm trying to
mitigate the damage on my side.

Their image destroys the meaningfulness of flag:attach. I've noticed
lately that dovecot added a flag to control how to treat the attachment
flag: inline attachments can now be ignored for the flag.

I can see plenty of cases where this would fail (inline text patches,
for one), but it looks like the basis of a good approach.

I wonder if there is something similar in the mu backend?

Ideally I would love a hook when receiving to simply kill the signature,
but this being an html message with inline content, it's just painful to
implement properly.

[Dirk-Jan C. Binnema]

You might be able to kill off the attachments using some mime
manipulation tool, with a bit of scripting.

On the mu4e side, you could customize `mu4e-header-info-custom' and
create your own field, say `:my-flags', which would do what `:flags'
does but with some filter for the attach flag (in the header view,
there's only limited information about messages though... but you use
`:size' as heuristic.

Otherwise, on the mu side you could checkout `mu-msg-part.c', in
particular towards the end, `mu_msg_part_maybe_attachment'.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

[Yuri D'Elia]

On Sat, Mar 10 2018, Dirk-Jan C. Binnema wrote:
> You might be able to kill off the attachments using some mime
> manipulation tool, with a bit of scripting.

Do you do this already in any way? (in the sense of acting on incoming
messages before they're indexed)

I'd like to post-process incoming messages after isync fetches them,
however isync itself doesn't offer a convenient hook.

> Otherwise, on the mu side you could checkout `mu-msg-part.c', in
> particular towards the end, `mu_msg_part_maybe_attachment'.

What do you think about dovecot's solution? I could do a PR implementing
the same options.

See:

https://wiki.dovecot.org/AttachmentIndicator

[Dirk-Jan C. Binnema]

On Saturday Mar 10 2018, Yuri D'Elia wrote:

> On Sat, Mar 10 2018, Dirk-Jan C. Binnema wrote:
>> You might be able to kill off the attachments using some mime
>> manipulation tool, with a bit of scripting.
>
> Do you do this already in any way? (in the sense of acting on incoming
> messages before they're indexed)

Mu in general doesn't know how the messages got into the maildir
structure. But you can set up e.g. procmail and the like to arbitrary
things with incoming messages.

One of my future plans (right after world domination) is to allow mu to
do something like that -- i.e., some kind of "new message hook" to
manipulate messages; but for now procmail or its ilk are your best bet
for the pre-indexing stage.

> I'd like to post-process incoming messages after isync fetches them,
> however isync itself doesn't offer a convenient hook.
>
>> Otherwise, on the mu side you could checkout `mu-msg-part.c', in
>> particular towards the end, `mu_msg_part_maybe_attachment'.
>
> What do you think about dovecot's solution? I could do a PR implementing
> the same options.
>
> See:
>
> https://wiki.dovecot.org/AttachmentIndicator

Dovecot encodes these keywords in the local filenames?

[Yuri D'Elia]

On Sat, Mar 10 2018, Dirk-Jan C. Binnema wrote:
>> I'd like to post-process incoming messages after isync fetches them,
>> however isync itself doesn't offer a convenient hook.

Ok, but using procmail or something else needs to know which messages
are still unprocessed. Ideally I wouldn't want to move messages and/or
remove the new flag to handle this.

>> https://wiki.dovecot.org/AttachmentIndicator
>
> Dovecot encodes these keywords in the local filenames?

Not sure honestly, but it doesn't matter for several reasons.

My main question was if you like the idea/approach to detect useless
attachments. We would basically have to reimplement it anyway.

Dovecot simply exposes the $HasAttachment keyword over IMAP. What it
does internally is useless. The better question would be whether isync
passes this on (which I doubt).

[Yuri D'Elia]

On Sat, Mar 10 2018, Yuri D'Elia wrote:
> On Sat, Mar 10 2018, Dirk-Jan C. Binnema wrote:
>>> I'd like to post-process incoming messages after isync fetches them,
>>> however isync itself doesn't offer a convenient hook.
>
> Ok, but using procmail or something else needs to know which messages
> are still unprocessed. Ideally I wouldn't want to move messages and/or
> remove the new flag to handle this.

Probably I should add that this is required when you do a bi-directional
sync using something like isync/offlineimap.

Dumb fetching wouldn't have this problem.

[Dirk-Jan C. Binnema]

On Saturday Mar 10 2018, Yuri D'Elia wrote:

> On Sat, Mar 10 2018, Dirk-Jan C. Binnema wrote:
>>> I'd like to post-process incoming messages after isync fetches them,
>>> however isync itself doesn't offer a convenient hook.
>
> Ok, but using procmail or something else needs to know which messages
> are still unprocessed. Ideally I wouldn't want to move messages and/or
> remove the new flag to handle this.

It's possible to use the file time for this; after an isync, if the
message is newer than the previous-isync etc.

>>> https://wiki.dovecot.org/AttachmentIndicator
>>
>> Dovecot encodes these keywords in the local filenames?
>
> Not sure honestly, but it doesn't matter for several reasons.
>
> My main question was if you like the idea/approach to detect useless
> attachments. We would basically have to reimplement it anyway.

Ah, so you meant this dovecot-attachment business as just an example
where a pre-index hook would be usable?

Anyway, a way to filter out useless filler attachments etc. might be
useful, but not at the cost of a lot additional complexity. So, for now
at least I think it's better to use something external; we could perhaps
add some example to the manual.

[Yuri D'Elia]

On Sun, Mar 18 2018, Dirk-Jan C. Binnema wrote:
>> My main question was if you like the idea/approach to detect useless
>> attachments. We would basically have to reimplement it anyway.
>
> Ah, so you meant this dovecot-attachment business as just an example
> where a pre-index hook would be usable?

Yep.