Re: Identifying messages with no To: or CC: headers?
On Fri, Sep 02, 2022 at 04:03:22PM -0400, John Hawkinson wrote: >> Could you not prepend your EXPR with something like this? >> >> `^(Delivered|Envelope)-To:\ ` > > I belive that you want this to be all-lowercase, because those headers > can be any case, and mutt will search case-insensitively per sec. 8.3 > of the manual: > >> As for regular expressions, a lower case string search pattern makes >> Mutt perform a case-insensitive search except for IMAP (because for >> IMAP Mutt performs server-side searches which don't support >> case-insensitivity). Good catch, thanks! -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Identifying messages with no To: or CC: headers?
On 2022-09-02 17:42, Todd Zullinger wrote:
> Tim Chase wrote:
>> color index reverse brightblack black "~h ^(delivered|envelope)-to:\
>> +[0-9a-f]{5,}[.][0-9a-f]{5,}@mydomain.com)$"
>>
>> Mutt complains
>>
>> Error in [my muttrc]: '^(delivered': parentheses not balanced
>>
>> which looks like the "|" is getting higher precedence than the
>> parens.
>
> Quote the pattern, as you would if using ~h in a limit
> statement:
>
> color index reverse brightblack black "~h '^(delivered|envelope)-to:
> +[0-9a-f]{5,}[.][0-9a-f]{5,}@mydomain.com)$'"
Ah, that double-quoting is what I missed. Works like a charm.
Thanks so much!
-tkc
Re: Identifying messages with no To: or CC: headers?
Tim Chase wrote:
> On 2022-09-02 19:45, Sam Kuper wrote:
>> Could you not prepend your EXPR with something like this?
>>
>> `^(Delivered|Envelope)-To:\ `
>
> Ah, so the pattern for matching ~h includes the header-name then
> and the regex can match against that? That should work.
>
> However, when I tried this
>
> color index reverse brightblack black "~h ^(delivered|envelope)-to:\
> +[0-9a-f]{5,}[.][0-9a-f]{5,}@mydomain.com)$"
>
> (tried with and without the backslash escaping the space)
>
> Mutt complains
>
> Error in [my muttrc]: '^(delivered': parentheses not balanced
>
> which looks like the "|" is getting higher precedence than the
> parens.
Quote the pattern, as you would if using ~h in a limit
statement:
color index reverse brightblack black "~h '^(delivered|envelope)-to:
+[0-9a-f]{5,}[.][0-9a-f]{5,}@mydomain.com)$'"
There shouldn't be any need to escape the space in the
pattern.
--
Todd
Re: Identifying messages with no To: or CC: headers?
On 2022-09-02 19:45, Sam Kuper wrote:
> On Fri, Sep 02, 2022 at 06:24:24PM +, Tim Chase wrote:
> > On 2022-09-02 20:07, Francesco Ariis wrote:
> >> Il 02 settembre 2022 alle 18:01 Tim Chase ha scritto:
> >>> However, often these messages don't have a To: or CC: header, so I
> >>> can't identify them with a ~C and I don't see an option for
> >>> identifying messages by the Delivered-To or Envelope-To headers.
> >>>
> >>> Is there a good way to identify these messages?
> >>
> >> Check ~h and =h, it those don???t do, consider filtering with your
> >> mail retriever (e.g getmail, that is what I use).
> >
> > Hmm, that looks like it might work. Is there further documentation
> > on the ~h beyond this:
> >
> > http://mutt.org/doc/manual/#tab-patterns
> >
> > It seems to mostly do what I want, but I don't see a way to limit
> > it to just the Delivered-To/Envelope-To headers,
>
> Could you not prepend your EXPR with something like this?
>
> `^(Delivered|Envelope)-To:\ `
Ah, so the pattern for matching ~h includes the header-name then
and the regex can match against that? That should work.
However, when I tried this
color index reverse brightblack black "~h ^(delivered|envelope)-to:\
+[0-9a-f]{5,}[.][0-9a-f]{5,}@mydomain.com)$"
(tried with and without the backslash escaping the space)
Mutt complains
Error in [my muttrc]: '^(delivered': parentheses not balanced
which looks like the "|" is getting higher precedence than the
parens.
Is this a more recent feature than my stock mutt-on-OpenBSD-RELEASE?
(version info below)
Thanks!
-tkc
$ mutt -v
Mutt 2.2.3 (2022-04-12)
Copyright (C) 1996-2022 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: OpenBSD 7.1 (amd64)
ncurses: ncurses 5.7.20081102 (compiled with 5.7)
libiconv: 1.16
libidn2: 2.3.0 (compiled with 2.3.0)
hcache backend: qdbm 1.8.78
Compiler:
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.1
Thread model: posix
InstalledDir: /usr/bin
Configure options: '--enable-compressed' '--enable-external_dotlock'
'--disable-fcntl' '--enable-flock' '--enable-hcache' '--with-idn2'
'--enable-imap' '--enable-pop' '--enable-sidebar' '--enable-smtp'
'--without-gdbm' '--without-tokyocabinet' '--with-qdbm'
'--with-docdir=/usr/local/share/doc/mutt' '--with-ssl' '--enable-autocrypt'
'--enable-gpgme' '--with-sqlite3' '--with-curses' '--prefix=/usr/local'
'--sysconfdir=/etc/mutt' '--mandir=/usr/local/man' '--infodir=/usr/local/info'
'--localstatedir=/var' '--disable-silent-rules' '--disable-gtk-doc' 'CC=cc'
'CFLAGS=-O2 -pipe -g' 'LDFLAGS=-L/usr/local/lib' 'CPPFLAGS=-I/usr/local/include'
Compilation CFLAGS: -Wall -pedantic -Wno-long-long -O2 -pipe -g
Compile options:
-DOMAIN
-DEBUG
-HOMESPOOL -USE_SETGID -USE_DOTLOCK +DL_STANDALONE -USE_FCNTL +USE_FLOCK
+USE_POP +USE_IMAP +USE_SMTP
+USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL -USE_GSASL -USE_GSS
+HAVE_GETADDRINFO
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +HAVE_FUTIMENS
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET
+HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_LIBIDN2 +HAVE_GETSID
+USE_HCACHE
+USE_SIDEBAR +USE_COMPRESSED -USE_INOTIFY
ISPELL="/usr/local/bin/ispell"
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/local/share/mutt"
SYSCONFDIR="/etc/mutt"
EXECSHELL="/bin/sh"
-MIXMASTER
Re: Identifying messages with no To: or CC: headers?
> Could you not prepend your EXPR with something like this? > > `^(Delivered|Envelope)-To:\ ` I belive that you want this to be all-lowercase, because those headers can be any case, and mutt will search case-insensitively per sec. 8.3 of the manual: > As for regular expressions, a lower case string search pattern makes Mutt > perform a case-insensitive search except for IMAP (because for IMAP Mutt > performs server-side searches which don't support case-insensitivity). Of course, you have to lower-case your EXPR (expr?) too. It would be nice if we had a better way to do that. -- jh...@alum.mit.edu John Hawkinson
Re: Identifying messages with no To: or CC: headers?
On Fri, Sep 02, 2022 at 06:24:24PM +, Tim Chase wrote: > On 2022-09-02 20:07, Francesco Ariis wrote: >> Il 02 settembre 2022 alle 18:01 Tim Chase ha scritto: >>> However, often these messages don't have a To: or CC: header, so I >>> can't identify them with a ~C and I don't see an option for >>> identifying messages by the Delivered-To or Envelope-To headers. >>> >>> Is there a good way to identify these messages? >> >> Check ~h and =h, it those don???t do, consider filtering with your >> mail retriever (e.g getmail, that is what I use). > > Hmm, that looks like it might work. Is there further documentation > on the ~h beyond this: > > http://mutt.org/doc/manual/#tab-patterns > > It seems to mostly do what I want, but I don't see a way to limit > it to just the Delivered-To/Envelope-To headers, As Obi-Wan Kenobi didn't say, "Use regular expressions, Luke!" Could you not prepend your EXPR with something like this? `^(Delivered|Envelope)-To:\ ` (Remove the backticks, of course. But don't forget the space after the backslash.) WFM. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Identifying messages with no To: or CC: headers?
On 2022-09-02 20:07, Francesco Ariis wrote: > Il 02 settembre 2022 alle 18:01 Tim Chase ha scritto: > > However, often these messages don't have a To: or CC: header, so I > > can't identify them with a ~C and I don't see an option for identifying > > messages by the Delivered-To or Envelope-To headers. > > > > Is there a good way to identify these messages? > > Check ~h and =h, it those don???t do, consider filtering with your > mail retriever (e.g getmail, that is what I use). Hmm, that looks like it might work. Is there further documentation on the ~h beyond this: http://mutt.org/doc/manual/#tab-patterns It seems to mostly do what I want, but I don't see a way to limit it to just the Delivered-To/Envelope-To headers, and sometimes my Message-ID headers match this pattern (which is how I think these oddball addresses got into the wild in the first place) so it mistakenly flags these messages, too. Thanks! -tkc
Re: Identifying messages with no To: or CC: headers?
Hello Tim, Il 02 settembre 2022 alle 18:01 Tim Chase ha scritto: > However, often these messages don't have a To: or CC: header, so I > can't identify them with a ~C and I don't see an option for identifying > messages by the Delivered-To or Envelope-To headers. > > Is there a good way to identify these messages? Check ~h and =h, it those don’t do, consider filtering with your mail retriever (e.g getmail, that is what I use).
Identifying messages with no To: or CC: headers?
I have a catch-all mailbox and would like to set up a filter/coloring
for spam messages coming to me of the form
[[:xdigit:]]{5,}[.][[:xdigit:]]{5,}@me.mydomain.com
according to the Delivered-To: or Envelope-To: headers. I suspect
they're comming from scraped message-IDs from messages I've sent
long ago.
However, often these messages don't have a To: or CC: header, so I
can't identify them with a ~C and I don't see an option for identifying
messages by the Delivered-To or Envelope-To headers.
Is there a good way to identify these messages?
Thanks!
-tkc
