messages sent from gmail appear in INBOX

[beo...@gmail.com]

I've had to switch my smtp provider to gmail, but when I send email,
I then get my sent email appearing in the INBOX in the email thread.

- I have this set for the email account in question
(mu4e-sent-messages-behavior delete)

- And my mu4e-user-mail-address-list includes the smtp email address,
i.e. mye...@gmail.com .

- And, I don't think it probably matters, but I also have set:

(setq mu4e-headers-skip-duplicates t)

What else do I need to do to keep this from happening?

thanks,
--
Benjamin Slade
`(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19))
'(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org )
'(Choose Linux, Choose Freedom . https://linux.com )

[Dirk-Jan C. Binnema]

Hi Beoram,

On Monday Jan 02 2017, beoram wrote:

> I've had to switch my smtp provider to gmail, but when I send email,
> I then get my sent email appearing in the INBOX in the email thread.
>
> - I have this set for the email account in question
> (mu4e-sent-messages-behavior delete)
>
> - And my mu4e-user-mail-address-list includes the smtp email address,
> i.e. mye...@gmail.com .
>
> - And, I don't think it probably matters, but I also have set:
>
> (setq mu4e-headers-skip-duplicates t)
>
> What else do I need to do to keep this from happening?

If you have the message you replied to still in your Inbox, and you use
mu4e in threaded mode, this is the expected behavior.

If not that, probably best to check your settings for
mbsync/offlineimap.

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

[Benjamin Slade]

I essentially fixed this.

For me, the root cause was sending mail using smtp.gmail which were not
actually "from: m...@gmail.com" (that is, just using gmail for the smtp
server) but instead "from: m...@uni.edu".

Two ways of addressing this:

1) in the custom mu4e bookmark which I use for viewing my combined
inboxes, I included a filter ...."AND NOT from:m...@uni.edu "... But this
only affects mu4e itself, and means the spurious emails are still
actually sitting in the Gmail inbox, so:

2) In gmail itself, set up a filter that matches "from:(m...@uni.edu)"
with the action "Delete it" and then in mu4e keep the setting:

(mu4e-sent-messages-behavior sent)

for this account rather than

(mu4e-sent-messages-behavior delete)

so that I still have a copy of the email in my Sent directory.

*->

That said, the very latest version of mu4e in the git repo seems to
break filtering. That is, in a thread, even if my bookmark settings
should filter out messages which are in ARCHIVED or SENT, they appear
anyway if they are part of the thread. Downgrading to the release version of mu4e resolves this.

—Ben
--
Dr Benjamin Slade

`(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19))
'(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org )
'(Choose Linux, Choose Freedom . https://linux.com )

> --
> You received this message because you are subscribed to the Google Groups "mu-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mu-discuss+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[J Irving]

On Saturday, January 14, 2017 at 1:50:26 PM UTC-5, Benjamin Slade wrote:

That said, the very latest version of mu4e in the git repo seems to
break filtering. That is, in a thread, even if my bookmark settings
should filter out messages which are in ARCHIVED or SENT, they appear
anyway if they are part of the thread. Downgrading to the release version of mu4e resolves this.

I noticed this and have been trying to understand what's going on, because it isn't immediately obvious that the behaviour is consistent.

For me, it manifests in a "... AND NOT flags:trashed ..." query, which includes trashed email being included (that is, email in my /Gmail/trashed maildir, which has "trashed" in its "flags" pseudo header) in the results. However, some combination of re-running my mbsync process and/or reindexing the database often results in them all going away.

Today, I saw another pattern which leads me to theorize that email which has been trashed is being included when it is part of a thread with non-trashed email in it. I noticed that I could re-mark all of these emails as trashed, and then execute the marks, and nothing would change, but then if I included the new emails in those thread in my marks, *all* of them would disappear correctly.

Note that this behaviour is different from what I see when I mark things "deleted". In that case, they disappear completely and never reappear, even if their threads are resurrected.

So now I'm thinking that perhaps this is an intentional behaviour change that I haven't quite grasped and not a bug. Still, if a query contains "... AND NOT flags:trashed ...", and it returns results which have the "trashed" flag set, I find it hard to not interpret it as a bug.

cheers, J

[Dirk-Jan C. Binnema]

When you ask mu4e (or mu) to do a query which includes "related"
messages, it first runs a query for messages that match your query, then
does a second query for all messages with message-ids referred to in the
first query.

I.e.,
"( ... AND NOT flag:trashed) OR ( related )"

There's no behavioral change here, it's always been like this.

If you don't want to see those trashed messages, you can either query in
non-related mode, or filter them out later -- see
`mu4e-headers-hide-predicate'.

[Dirk-Jan C. Binnema]

Hi Benjamin,

On Saturday Jan 14 2017, Benjamin Slade wrote:

> That said, the very latest version of mu4e in the git repo seems to
> break filtering. That is, in a thread, even if my bookmark settings
> should filter out messages which are in ARCHIVED or SENT, they appear
> anyway if they are part of the thread. Downgrading to the release
> version of mu4e resolves this.

I think the only relevant change is that `mu4e-headers-include-related'
changed its default to t. So perhaps that causes the surprise.

[J Irving]

>>>>>> Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> at 2017-01-22T14:33:58-0500:

> When you ask mu4e (or mu) to do a query which includes "related"
> messages, it first runs a query for messages that match your query, then
> does a second query for all messages with message-ids referred to in the
> first query.

> I.e.,
> "( ... AND NOT flag:trashed) OR ( related )"

> There's no behavioral change here, it's always been like this.

> If you don't want to see those trashed messages, you can either query in
> non-related mode, or filter them out later -- see
> `mu4e-headers-hide-predicate'.

Thanks, looking at the docstring for that variable gave me the
information I needed to fix this.

If there has been no change in behaviour, I wonder why I saw a change in
bahaviour without changing my configuration.

--
Jonathan Irving
http://j0ni.ca

[J Irving]

>>>>>> Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> at 2017-01-22T14:46:56-0500:

> I think the only relevant change is that `mu4e-headers-include-related'
> changed its default to t. So perhaps that causes the surprise.

This also solved my problem (including if I leave
`mu4e-headers-hide-predicate` unchanged), and sounds quite likely to
have been cause of the change of behaviour I saw.

Thanks.