Re: Is linewrap dead?
On Wed, Aug 31, 2022 at 07:45:05PM -0400, John Hawkinson wrote: > Derek Martin wrote on Wed, 31 Aug 2022 > at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>: > > Evaluating the strength of a SHOULD requires looking at pragmatic > realities. And that reality is that lots of messages are sent > without hard line wraps. That's true but the vast majority of that is HTML mail, which has entirely different set of formatting rules and display parameters, and again, not applicable here. > Also, RFC5322 is not intended to be a standard that governs what > user should do. It's for MTAs and MUAs and other mail software. This is clearly not true, since it is the standard for the format of the message, and the stated purpose is to ensure that recipients are not negatively impacted by implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line. This isn't about transmission, it's about interface and display. The user, far more than the MUA, controls the format of the message by how they construct the message, which in your case does indeed "disastrously wrap, the display of more than 78 characters per line" on my end. Your MUA does nothing to correct it--though I could force mine to. But as you say, it's extra work that is annoying, and I've only even seen people do what you're doing a handful of times since the 80's... usually by accident, or because they were brand-new e-mail users unfamiliar with the etiquette... And for the record, of the 8 people posting in this subthread (starting with your post), 2 of them complained about your practice. Perhaps your messages aren't as universally readable as you think. Anyway, the reason this conversation ultimately never goes anywhere useful is because there's already a perfectly viable means of achieving your goal: HTML mail. Pretty formatting is literally what it's for, and unlike format=flowed, or anything else you can imagine, it's already widely adopted. That fact is largely why nothing else will ever will be (at least until the next new thing is invented with capabilities far superseeding HTML). If you're so concerned with ugly wrapping, that's what you should be using. Otherwise, you should wrap your lines like the standards and existing conventions say you should. If it's just jagged right margins you don't like that's easily fixed by justifying the text in your editor--solutions exist for common editors, google them. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
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: trouble with my_hdr and $format_flowed [SOLVED]
On 02Sep2022 15:27, Cameron Simpson wrote: On 01Sep2022 20:18, Kevin J. McCarthy wrote: I'm not sure if it helps at this point, but I can report that I've taken your template above and passed it to 'mutt -H' and the resulting sent file has format=flowed in its content-type header. :-/ Can you try directly doing this too, outside of your tmux-editing framework? Yes. I should have done that already. [...] I'll be back after I've done some cleaner experiments. So, a bare "mutt -H" here acts like yours, honouring the Content-Type header. This points the finger directly at my script, where I discovered a problem. First up, it is necessary to hand apply a Content-Type header to the template file (as implied by the $text_flowed documentation). Second, my script was: - grabbing the template filename from the command line as $filename - making the copy to be used by the tmux session's "mutt -H" as $tmpf - patching the copy with a Content-Type header - assigning filename=$tmpf after the copy was complete, for use in the following code During debugging I'd stuck that in a subshell, a habit when I turn on "set -x" in a script, thus: blah blah ... ( set -x code beging traced ... ... ) So the filename= assignment was lost, and the subsequent run-in-tmux code was using the unpatched no-Content-Type file. Fixed and deployed. This message should be format=flowed. Cheers, Cameron Simpson
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: Having problems with POP3 setup
On Fri, Sep 02, 2022 at 01:11:53PM -0500, X Tec wrote: > On 2022-08-31 11:46:15, X Tec wrote: >> On 2022-08-30 18:34:42, Kevin J. McCarthy wrote: >>> On Mon, Aug 29, 2022 at 03:14:21PM -0500, X Tec wrote: Fetching email with 'G' key just ignores the "pop_last=yes" setting because it always downloads all email regardless of locally read or not, even though other clients such as Outlook or Thunderbird don't do this mistake. So I don't think server doesn't support the LAST command... >>> >>> Run with debugging enabled (-d 2) and check the log file to see >>> what the LAST command response is from the server. Since the >>> command was deprecated some time ago, I would venture the server is >>> returning an unknown command error. >> >> With debugger I saw this line: "-ERR Unknown command: LAST"; so I >> think you were right once again... OK, so that's that mystery resolved. >>> Mutt's POP3 support *is* simple, so if LAST isn't supported, the >>> behavior you are seeing with is expected. >>> >>> You may be happier just directly connecting to a pops:// URL via >>> one of your mailboxes instead; or with a more sophisticated tool, >>> such as Getmail (which Sam mentioned). >> >> So if I wanted this function, or the one of "keep messages in server >> for x days", would I need another external POP3 mail fetcher? Yes. There is one caveat. If the POP3 server is totally kooky, then even Getmail or suchlike might be unable to extract the desired behaviour from it. Fortunately, nothing so far seems particularly kooky about the POP3 server in your case. >> I did read in the Mutt wiki that Mutt originally didn't intend to >> have native SMTP support, but it ended up (reluctantly?) being added >> eventually; which is why I decided to learn Msmtp as well. However, I >> was unable to find any proof of this being the same case for IMAP and >> POP3, and I searched the whole wiki and docs. So I thought "so unlike >> SMTP, Mutt has always been supposed to support IMAP and POP3 >> natively". >> >> But then, must I understand that this is *not* the case for POP3? > > Could someone still help with these issues please? Mutt *does* support POP3, but as Kevin pointed out above, its POP3 support is simple, i.e. basic. If you want a more sophisticated MRA (i.e. POP3 client), then a third-party MRA such as Getmail will likely suit you better. Mutt roughly adheres to the Unix philosophy - "Make each program do one thing well." Mutt is an *amazing* MUA. It does not excel at anything else. (Nor should it.) Yes, Mutt has MRA and MTA capabilities, but these are limited. It is *good* that these capabilities are limited because that keeps the codebase, and the consequent bug surface and attack surface, small. (Purists might argue that Mutt should not have MRA or MTA capabilities at *all* - but for better or worse, the pragmatists who argued Mutt should have limited MRA and MTA capabilities got their way.) So, if you want an *amazing* lightweight MTA to sit alongside Mutt, msmtp is a great choice - and it seems you made that choice. Ace! Similarly, if you want an *amazing* lightweight MRA to sit alongside Mutt, Getmail is a great choice. Good luck, 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 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: Having problems with POP3 setup
Could someone still help with these issues please?
Thanks.
On 2022-08-31 11:46:15, X Tec wrote:
> With debugger I saw this line: "-ERR Unknown command: LAST"; so I think you
> were right once again...
> So if I wanted this function, or the one of "keep messages in server for x
> days", would I need another external POP3 mail fetcher?
> I did read in the Mutt wiki that Mutt originally didn't intend to have native
> SMTP support, but it ended up (reluctantly?) being added eventually; which is
> why I decided to learn Msmtp as well. However, I was unable to find any proof
> of this being the same case for IMAP and POP3, and I searched the whole wiki
> and docs. So I thought "so unlike SMTP, Mutt has always been supposed to
> support IMAP and POP3 natively".
> But then, must I understand that this is *not* the case for POP3?
>
>
>
> > ---A more general thing: what are Ctrl+O ("open mailbox") and '$' actually
> > for?
> > On IMAP Ctrl+O is the only one updating the mailboxes; '$' just says
> > "mailbox is unchanged" even if there are being new messages at that instant
> > (I have tested it), and only does stuff only if there are messages marked
> > for deletion
> > On POP3 both Ctrl+O and '$' seem to do nothing at all, and only 'G'
> > downloads messages
>
> Could someone still help a bit with this too? I use Ctrl+O because I do use
> sidebar; without it I have no idea of how to manually "update/refresh" IMAP
> folders...
>
>
>
> > ---Finally, on IMAP, different email providers seem to have totally
> > different ways to specify their subfolders for the variables $sent,
> > $drafts...: "INBOX.sent", "[Gmail]/Sent Mail", etc. Then how am I supposed
> > to find out which syntax each email service uses?
>
> So this has really no solution?
>
>
>
> Thanks again beofrehand for your attention.
>
>
>
> > On 2022-08-30 18:34:42, Kevin J. McCarthy wrote:
> > > On Mon, Aug 29, 2022 at 03:14:21PM -0500, X Tec wrote:
> > > > Fetching email with 'G' key just ignores the "pop_last=yes" setting
> > > > because it always downloads all email regardless of locally read or not,
> > > > even though other clients such as Outlook or Thunderbird don't do this
> > > > mistake. So I don't think server doesn't support the LAST command...
> > >
> > > Run with debugging enabled (-d 2) and check the log file to see what the
> > > LAST command response is from the server. Since the command was
> > > deprecated
> > > some time ago, I would venture the server is returning an unknown command
> > > error.
> > >
> > > Mutt's POP3 support *is* simple, so if LAST isn't supported, the behavior
> > > you are seeing with is expected.
> > >
> > > You may be happier just directly connecting to a pops:// URL via one of
> > > your
> > > mailboxes instead; or with a more sophisticated tool, such as Getmail
> > > (which
> > > Sam mentioned).
> > >
> > > --
> > > Kevin J. McCarthy
> > > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
> >
> >
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
