Re: Threads based on a custom header

dm1...@gmail.com wrote: > Hi all, > > Is it possible to display messages (preferably automatically, as soon > as the messages get in the mailbox) as one thread based on a value of > a custom header? That is, all the messages that have the X header with > the same value. If

Threads based on a custom header

Hi all, Is it possible to display messages (preferably automatically, as soon as the messages get in the mailbox) as one thread based on a value of a custom header? That is, all the messages that have the X header with the same value. Best, -- Dmitry

Re: Why Mail-Followup-To header for a non-list address?

On Sun, Aug 20, 2023 at 06:25:57PM +0800, "Kevin J. McCarthy" wrote: > On Sun, Aug 20, 2023 at 03:53:09PM +1000, raf via Mutt-users wrote: > > I don't have any "lists" commands. I do have a "subscribe" command > > which refers to mailing lists by their aliases. One of the aliases > > is

Re: Why Mail-Followup-To header for a non-list address?

On Sun, Aug 20, 2023 at 03:53:09PM +1000, raf via Mutt-users wrote: I don't have any "lists" commands. I do have a "subscribe" command which refers to mailing lists by their aliases. One of the aliases is "debian" and the email address in question does contain "+debian" but that shouldn't

Why Mail-Followup-To header for a non-list address?

Hi, Someone recently emailed me. Technically it was a reply to an old email of mine. Since then, a few emails have gone back and forth between us. All of my outgoing mails to this one address have had a Mail-Followup-To header added. I have no idea why. The address isn't mentioned in any

Re: Problem with IMAP Server and Header Cache

Am 2023-01-26 20:08, schrieb Kevin J. McCarthy: the header cache backend, this smells like a Mutt bug. Would you mind opening a ticket so we can debug it without causing too much traffic on mutt-users? Yes agree, so let's move it to https://gitlab.com/muttmua/mutt/-/issues/436 Thanks

Re: Problem with IMAP Server and Header Cache

On Thu, Jan 26, 2023 at 05:07:50PM +0100, Christian Brabandt wrote: I tried building building latest master with --with-kyotocabinet Thank you for rebuilding and testing. Since the problem isn't with the header cache backend, this smells like a Mutt bug. Would you mind opening a ticket so

Re: Problem with IMAP Server and Header Cache

Am 2023-01-26 00:33, schrieb Kevin J. McCarthy: Hmmm... I see in the log that even in the "working" case it's taking a good 15 seconds to load in the messages from the seqset/header cache. It's a big mailbox, though, so maybe that's to be expected. I noticed you are using 1.13.2

Re: Problem with IMAP Server and Header Cache

On Wed, Jan 25, 2023 at 10:13:58PM +0100, Christian Brabandt wrote: No. I mean it happens whenever mutt quits (or has been forcefully shutdown). Sometimes I also notice a normal quit takes very long (I assume it somehow writes/updates the header cache and this may also take a while?) I can

Re: Problem with IMAP Server and Header Cache

Sometimes I also notice a normal quit takes very long (I assume it somehow writes/updates the header cache and this may also take a while?) I can "fix" it by manually deleting the header cache, but then mutt starts loading all those messages again and it again takes a bit until the mailbo

Re: Problem with IMAP Server and Header Cache

(Up until the "Fetching flag updates..." part). My first guess is that the seqset is corrupted somehow, or perhaps the header cache has a problem, but that wouldn't explain why it sometimes works. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031

Problem with IMAP Server and Header Cache

25 11:44:22] 4< * OK [UNSEEN 4] First unseen. [2023-01-25 11:44:22] 4< * OK [UIDVALIDITY 1384369187] UIDs valid [2023-01-25 11:44:22] 4< * OK [UIDNEXT 351036] Predicted next UID [2023-01-25 11:44:22] 4< * OK [HIGHESTMODSEQ 166330] Highest [2023-01-25 11:44:22] 4< a0080 OK [READ-WRITE

Re: Two questions regarding header display

On Mon, Jun 20, 2022 at 08:15:13AM +1000, Cameron Simpson wrote: > On 07Jun2022 09:56, raf wrote: > >And I'm not sure I can do anything about it. > > There are many things you can do. I see you've already shifted to just > using "bold" etc in your color directives, but also: > - run a

Re: Two questions regarding header display

* Bastian [06-20-22 08:33]: > I did not follow the entire thread, sorry for potential double post. > On 20Jun22 08:15+1000, Cameron Simpson wrote: > > On 07Jun2022 09:56, raf wrote: > > >And I'm not sure I can do anything about it. > > There are many things you can do. I see you've already

Re: Two questions regarding header display

On 07Jun2022 09:56, raf wrote: >And I'm not sure I can do anything about it. There are many things you can do. I see you've already shifted to just using "bold" etc in your color directives, but also: - run a personal terminfo record without the color capabilities; decompile the provided

Re: Two questions regarding header display

37 2020 +0200). Still no 5.0 tag in git. Most recent v4.9.0 version branch has _lot_ of commits which are not on master at all, may be meanwhile has even italic support merged in. On Wed, Jun 08, 2022 at 11:18:22AM +1000, raf wrote: > > Thanks. It'll probably work if I just switch from &

Re: Two questions regarding header display

tives to "color" directives and tell it to use bold and default colours. Yep, that did it: color header bold default default ^(Subject|From|To|Cc|Date): cheers, raf

Re: Two questions regarding header display

raf schrieb am Di., 7. Juni 2022, 01:57: > TERM=screen. > > It's OK. screen is more important to me than bold > headers. > Don't give up. Gnu screen definitely supports bold if running on xterm, i see it all the time - in my vim at least, not configured in mutt yet by now. TERM value is

Re: Two questions regarding header display

On Mon, Jun 06, 2022 at 09:53:35AM -0700, "Kevin J. McCarthy" wrote: > On Tue, Jun 07, 2022 at 12:37:59AM +1000, raf wrote: > > On Sun, Jun 05, 2022 at 07:02:24PM -0700, "Kevin J. McCarthy" > > wrote: > > > TERM=xterm-mono might work for you > > > > Thanks, but that didn't change it. > >

Re: Two questions regarding header display

On Tue, Jun 07, 2022 at 12:37:59AM +1000, raf wrote: On Sun, Jun 05, 2022 at 07:02:24PM -0700, "Kevin J. McCarthy" wrote: TERM=xterm-mono might work for you Thanks, but that didn't change it. Interesting. It works for me, at least on Debian in an xterm. You may want to check your

Re: Two questions regarding header display

On Sun, Jun 05, 2022 at 07:02:24PM -0700, "Kevin J. McCarthy" wrote: > On Mon, Jun 06, 2022 at 10:57:47AM +1000, raf wrote: > > And there's also the "mono" directive for terminals that > > don't support colour, e.g.: > > > > mono header bold ^(Su

Re: Two questions regarding header display

On Mon, Jun 06, 2022 at 10:57:47AM +1000, raf wrote: And there's also the "mono" directive for terminals that don't support colour, e.g.: mono header bold ^(Subject|From|To|Cc|Date): But it doesn't work for me anymore (with TERM=xterm). TERM=xterm-mono might work for you An

Re: Two questions regarding header display

On Sun, Jun 05, 2022 at 09:33:43AM -0700, "Kevin J. McCarthy" wrote: > On Sun, Jun 05, 2022 at 10:24:47AM -0400, Jason Franklin wrote: > > On Sun, Jun 05, 2022 at 09:26:04AM +0200, Jakub Jindra wrote: > > > set header_color_partial = yes > > > color hdrdef

Re: Two questions regarding header display

On Sun, Jun 05, 2022 at 10:24:47AM -0400, Jason Franklin wrote: On Sun, Jun 05, 2022 at 09:26:04AM +0200, Jakub Jindra wrote: set header_color_partial = yes color hdrdefault FG BG color header FG BG "REGEX" color header FG1 BG1 "REGEX1" tune the colors FG, BG and

Re: Two questions regarding header display

On Sun, Jun 05, 2022 at 09:26:04AM +0200, Jakub Jindra wrote: > Hi Jason, > > You're looking for config option [1]header_color_partial > > 1. http://www.mutt.org/doc/manual/#header-color-partial > > set header_color_partial = yes > color hdrdefault FG BG > colo

Re: Two questions regarding header display

On Sun, Jun 05, 2022 at 09:51:29PM +1000, raf wrote: > On Sun, Jun 05, 2022 at 11:32:34AM +0200, Anton Sharonov > wrote: > > Will usage of display_filter option with your perl script below not be > > already sufficient solution even without procmail? > > Good thinking. I just tried it and it

Re: Two questions regarding header display

On Sun, Jun 05, 2022 at 11:32:34AM +0200, Anton Sharonov wrote: > raf schrieb am So., 5. Juni 2022, 07:52: > > > On Sun, Jun 05, 2022 at 12:06:52AM -0400, Jason Franklin > > wrote: > > > > > Greetings: > > > > > > I have two questions

Re: Two questions regarding header display

raf schrieb am So., 5. Juni 2022, 07:52: > On Sun, Jun 05, 2022 at 12:06:52AM -0400, Jason Franklin > wrote: > > > Greetings: > > > > I have two questions regarding header display... > > > > First, can the pager display header names in bold if the termin

Re: Two questions regarding header display

Hi Jason, You're looking for config option [1]header_color_partial 1. http://www.mutt.org/doc/manual/#header-color-partial set header_color_partial = yes color hdrdefault FG BG color header FG BG "REGEX" color header FG1 BG1 "REGEX1" tune the colors FG, BG and

Re: Two questions regarding header display

On Sun, Jun 05, 2022 at 12:06:52AM -0400, Jason Franklin wrote: > Greetings: > > I have two questions regarding header display... > > First, can the pager display header names in bold if the terminal > supports it? > > Second some senders have weird capitalization of

Two questions regarding header display

Greetings: I have two questions regarding header display... First, can the pager display header names in bold if the terminal supports it? Second some senders have weird capitalization of headers. Is it possible to display some canonical representation of any given standard header? To clarify

Turning off 'Sender' header for mailing list

Hi Everyone, Recently Gmail has started bouncing emails with any DKIM failures. One source of these failures is the: 'Sender: Mutt-users ' header added by the mailing list. I realize some of you may be filtering based on that header, but I'm seeing a large number of bounce-unsubscribes

Re: Filter script to remove html, fullquotes and header lines

Am 2022-03-22 um 01:56 schrieb raf: On Mon, Mar 21, 2022 at 01:28:28PM +0100, Martin Trautmann wrote: Am 2022-03-21 um 12:56 schrieb raf: textmail can probably do at least some of what you want: https://raf.org/textmail https://github.com/raforg/textmail and it has some

Re: Filter script to remove html, fullquotes and header lines

On Mon, Mar 21, 2022 at 01:28:28PM +0100, Martin Trautmann wrote: > Am 2022-03-21 um 12:56 schrieb raf: > > textmail can probably do at least some of what you want: > > > >https://raf.org/textmail > >https://github.com/raforg/textmail > > > > and it has some extensibility so you can

Re: Filter script to remove html, fullquotes and header lines

delete > >a fullquote up to there and remove xzxzxzx again? > > > >  Bonus: Do not remove fullquotes for messages without in-reply-to or > >references headers. > > > >3) remove header lines which are longer than 5 lines > > > >I want to shrink the size

Re: Filter script to remove html, fullquotes and header lines

Am 2022-03-21 um 12:56 schrieb raf: textmail can probably do at least some of what you want: https://raf.org/textmail https://github.com/raforg/textmail and it has some extensibility so you can supply external translation programs for the bits it doesn't do. it can operate on individual

Re: Filter script to remove html, fullquotes and header lines

On Mon, Mar 21, 2022 at 07:18:01AM +0100, Martin Trautmann wrote: > Am 2022-03-20 um 22:46 schrieb Cameron Simpson: > > I think you'll have to write your own. > > I agree - but I hoped it could have been done with some fine tuning of an > existing script. > > > > At minimum you need a full

Re: Filter script to remove html, fullquotes and header lines

Am 2022-03-20 um 22:46 schrieb Cameron Simpson: I think you'll have to write your own. I agree - but I hoped it could have been done with some fine tuning of an existing script. At minimum you need a full mail message parser so that you are not filtering, say, base64 or QP content

Re: Filter script to remove html, fullquotes and header lines

gt;   and at least e.g. 10 occurences > >  such as (^>[.*][\r\n]){9,} before the end of the message > >  Maybe I could append xzxzxzx to the end of the message first, delete >a fullquote up to there and remove xzxzxzx again? > >  Bonus: Do not remove fullquotes for messages without in-repl

Filter script to remove html, fullquotes and header lines

d of the message   Maybe I could append xzxzxzx to the end of the message first, delete a fullquote up to there and remove xzxzxzx again?   Bonus: Do not remove fullquotes for messages without in-reply-to or references headers. 3) remove header lines which are longer than 5 lines I want to

Is there any access to header values in muttrc file?

Is there any way to 'see' header values from send-hook? I want to be able to manipulate the To: address in an external program so I want to do something like:- send-hook 'barges.org/discussion-forum' 'source myscript.sh $to|' I.e. I want the To: address fed into myscript.sh. -- Chris

Re: Using UTC time in Date header

On Sun, May 16, 2021 at 10:32:33AM +1000, raf wrote: > > When my workplace switched to office365 (all but me anyway), > their emails started arriving with UTC date headers. So I > wrote a procmail recipe to filter incoming emails through > a little perl script to convert the da

Re: Using UTC time in Date header

ones that my brain is facile with the trivial > arithmetic for (i.e. US/Eastern, US/Central, US/Pacific, and I suppose > the rare US/Mountain). > > But when a header comes in UTC, I'd much rather convert it to local > time, especially so I don't have to think about h

Re: Using UTC time in Date header

On Fri, 14 May 2021 19:57 -0600, Gregory Anders wrote: For example, I am one of those (rare) US/Mountain time zones, so I know I just need to subtract 6 from any UTC time to get my local time (7 during DST). Of course I got these backwards: it's 6 during DST and 7 otherwise. Maybe I just

Re: Using UTC time in Date header

I don't mean to invalidate your opinion, but I don't think using UTC universally is actually all that bad. Each individual person just needs to know their own personal UTC offset and then it's trivial to adjust. In my opinion, when everyone uses their own local time zone it actually makes

Re: Using UTC time in Date header

Gregory Anders wrote on Fri, 14 May 2021 at 21:57:04 EDT in : > I don't mean to invalidate your opinion, but I don't think using UTC > universally is actually all that bad. Each individual person just needs to That may be nice for you, but most of the non-software-engineering normal humans I

Re: Using UTC time in Date header

/Central, US/Pacific, and I suppose the rare US/Mountain). But when a header comes in UTC, I'd much rather convert it to local time, especially so I don't have to think about how DST affects the offset. But also this is an issue for attributions. When I reply to someone, I want the attribution

Re: Using UTC time in Date header

n the date header. So, for example, showing mail arrival times in my local timezone no longer works. I sent a patch [1] to add a new 'local_date_header' option (enabled by default) that should enable this behavior, for anyone else who may be interested. Thanks, Greg [1]: https://lists.sr.ht

Re: Using UTC time in Date header

On Fri, May 14, 2021 at 02:22:43PM -0600, Gregory Anders wrote: > Hi all, > > The Date: header that Mutt adds to my sent emails includes my time zone > offset. I would prefer to have the header present the time of my email in > UTC time (offset 0). I wasn't able to find a settin

Using UTC time in Date header

Hi all, The Date: header that Mutt adds to my sent emails includes my time zone offset. I would prefer to have the header present the time of my email in UTC time (offset 0). I wasn't able to find a setting that controls this. In fact, I'm not sure how Mutt is getting my time zone at all

Re: Is it possible to use send-hook to 'edit' a header

ook should be run on. Also, running this based on the To header (rather than the From header) is better because if you use the list-reply function (bound to L in the index by default), then you _know_ what the To address will be (the mailing address of the list) (remember, this is the To address of

Re: Is it possible to use send-hook to 'edit' a header

- Chiraag -- ಚಿರಾಗ್ ನಟರಾಜ್ Pronouns: he/him/his 25/11/20 09:26 ನಲ್ಲಿ, Chris Green ಬರೆದರು: > > Is there some sort of action/command I can run from send-hook that > would allow 'editing' of a header? > > E.g. for the case I was recently enquiring about where groups.io munge >

Is it possible to use send-hook to 'edit' a header

Is there some sort of action/command I can run from send-hook that would allow 'editing' of a header? E.g. for the case I was recently enquiring about where groups.io munge certain senders' addresses the requirement would be to have a send-hook match on "via groups.io" in the Fro

Re: conditional automatic cc header?

Kevin J. McCarthy wrote: > On Thu, Apr 02, 2020 at 12:01:38PM +1100, raf wrote: > > Jens John wrote: > > > > > On Wed, 1 Apr 2020, at 06:22, raf wrote: > > > > e.g. Add a CC header to f...@work.com whenever > > > > sending/replyin

Re: conditional automatic cc header?

On Thu, Apr 02, 2020 at 12:01:38PM +1100, raf wrote: Jens John wrote: On Wed, 1 Apr 2020, at 06:22, raf wrote: e.g. Add a CC header to f...@work.com whenever sending/replying/forwarding from m...@work.com unless the email is already going to f...@work.com. I think a combination of hooks

Re: conditional automatic cc header?

Cameron Simpson wrote: > On 01Apr2020 12:34, Jens John wrote: > > Apologies for answering a solved thread; I received raf's followup only > > after reconnecting to the server when sending my reply. > > A different (and, better, "in mutt") solution is always welcome. The OP > might adopt it and

Re: conditional automatic cc header?

Jens John wrote: > On Wed, 1 Apr 2020, at 06:22, raf wrote: > > e.g. Add a CC header to f...@work.com whenever > > sending/replying/forwarding from m...@work.com unless the > > email is already going to f...@work.com. > > I think a combination of hooks or only

Re: conditional automatic cc header?

On 01Apr2020 12:34, Jens John wrote: Apologies for answering a solved thread; I received raf's followup only after reconnecting to the server when sending my reply. A different (and, better, "in mutt") solution is always welcome. The OP might adopt it and anyway the rest of us can learn

Re: conditional automatic cc header?

On Wed, 1 Apr 2020, at 06:22, raf wrote: > e.g. Add a CC header to f...@work.com whenever > sending/replying/forwarding from m...@work.com unless the > email is already going to f...@work.com. I think a combination of hooks or only a send2-hook could be used. How about someth

Re: conditional automatic cc header?

Apologies for answering a solved thread; I received raf's followup only after reconnecting to the server when sending my reply. Cheers.

Re: conditional automatic cc header?

raf wrote: > What's a good way to automatically add a Cc: header > for a particular address when sending/replying/forwarding? > But not if they're already going to receive the email. > And only when sending from a particular address. > > e.g. Add a CC header to f...@work.com

conditional automatic cc header?

Hi, What's a good way to automatically add a Cc: header for a particular address when sending/replying/forwarding? But not if they're already going to receive the email. And only when sending from a particular address. e.g. Add a CC header to f...@work.com whenever sending/replying/forwarding

Re: Setting From header based on To header

Kevin J. McCarthy wrote: > On Tue, Feb 18, 2020 at 10:47:31PM +0100, Jens Mueller wrote: > > I was looking for a way to set the From header based on the To header > > when replying in mutt. > > Check out $reverse_name and also $reverse_realname. It requires the To or

Re: Setting From header based on To header

On Tue, Feb 18, 2020 at 10:47:31PM +0100, Jens Mueller wrote: I was looking for a way to set the From header based on the To header when replying in mutt. Check out $reverse_name and also $reverse_realname. It requires the To or Cc address to match an entry in your alternates list

Setting From header based on To header

Hi, I have a mail account with aliased mail addresses, i.e., mails sent to me.someth...@example.com, me.somethinge...@example.com, etc. are delivered to m...@example.com. The To header indicates which alias an email was sent to, e.g, me.someth...@example.com. I was looking for a way to set

Re: X-Face: Header Interpretation

haviour. Certainly shows how these things should be better tested across platforms) [12] My script is somewhat tweaked - I use formail to get the headers more reliably, and also save the resulting pbm to disk in parallel to displaying it. But the header|icontopbm|viewer b

Re: X-Face: Header Interpretation

On Wed, May 29, 2019 at 02:21:22PM -0500, Hokan wrote: Should I submit a bug report to suggest that the Mutt Wiki page be updated to suggest this modification to the script? Sure, don't be shy. :-) You can also create a pull-request if you want to clone the wiki:

X-Face: Header Interpretation

Hello Mutters, For kicks, I thought I'd try making the X-Face header work and followed the instructions here: https://gitlab.com/muttmua/mutt/wikis/MuttGuide/XFace I installed the needed programs from the FreeBSD Ports system. I was able to create a header, but not view the image it contained

Re: Numbered SGML entities in header addresses

On 2019-04-11 19:12, Derek Martin wrote: > This may be one of the rarer cases where it's actually easier to > contact the sender and get them to do something more reasonable (and > standards-compliant) instead of working around their brokenness. I'll take this as the definitve answer, thanks ;-)

Re: Numbered SGML entities in header addresses

On Fri, Apr 12, 2019 at 11:25:20AM +0200, felixs wrote: > On Thu, Apr 11, 2019 at 07:12:57PM -0500, Derek Martin wrote: > > On Sun, Apr 07, 2019 at 11:13:53PM +0200, felixs wrote: > > > On Fri, Apr 05, 2019 at 11:24:26AM -0700, Ian Zimmerman wrote: > > Thanks. I had already posted a follow-up on

Re: Numbered SGML entities in header addresses

On Thu, Apr 11, 2019 at 07:12:57PM -0500, Derek Martin wrote: > On Sun, Apr 07, 2019 at 11:13:53PM +0200, felixs wrote: > > On Fri, Apr 05, 2019 at 11:24:26AM -0700, Ian Zimmerman wrote: > > > I think this is the first time I got hit by the next stage of > > > browserisation: on a mailing list, a

Re: Numbered SGML entities in header addresses

On Sun, Apr 07, 2019 at 11:13:53PM +0200, felixs wrote: > On Fri, Apr 05, 2019 at 11:24:26AM -0700, Ian Zimmerman wrote: > > I think this is the first time I got hit by the next stage of > > browserisation: on a mailing list, a From: line that looks like > > > > From: "Foo Bari" > > > where the

Re: Numbered SGML entities in header addresses

that mutt picks up those if the > "charset" mutt variable is not set. > > For another thing, why should it help? Those ASCII characters are > perfectly valid in the name part of a From header, and normally I expect > mutt to show them to me as they are. Sorry, at first glan

Re: Numbered SGML entities in header addresses

t mutt picks up those if the > "charset" mutt variable is not set. Yes, you are right, mutt reads the LC_* variables and is usually able to represent characters in utf-8 if that is set by them. But in case of problems, as I thought you might have, it may be a help to explicitly set it.

Re: Numbered SGML entities in header addresses

. For one thing, UTF-8 is the systemwide default, meaning it ends up in my LANG and LC_ variables. I am as sure as I can be about anything that mutt picks up those if the "charset" mutt variable is not set. For another thing, why should it help? Those ASCII characters are perfec

Re: Numbered SGML entities in header addresses

On Fri, Apr 05, 2019 at 11:24:26AM -0700, Ian Zimmerman wrote: > I think this is the first time I got hit by the next stage of > browserisation: on a mailing list, a From: line that looks like > > From: "Foo Bari" > > where the entity refers to the character U0107 in Unicode code point > space.

Numbered SGML entities in header addresses

I think this is the first time I got hit by the next stage of browserisation: on a mailing list, a From: line that looks like From: "Foo Bari" where the entity refers to the character U0107 in Unicode code point space. I would like to automatically see the correct glyph at least when it is in

Re: Limit number of fetched message headers WITHOUT using header cache/body cache?

On Mon, Mar 11, 2019 at 03:11:57PM +, Jaime T wrote: Is there a way to limit how many message headers mutt fetches? Not within Mutt, but Gmail has a "Folder size limits" setting to do so. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA

Limit number of fetched message headers WITHOUT using header cache/body cache?

the client. Is there a way to limit how many message headers mutt fetches? Ideally, I would like to fetch only the most recent 30 or so message headers, and I do *not* want to use "header caching" or "body caching". Many thanks.

Re: BCC from the FROM header

* Wim 03.06.2018 > On Sunday, 03 June at 08:29, Michael Wagner wrote: > > > I have a folder called 'privat' in which all the private mails from my 3 > > accounts are collected. When I answer to a mail, I want to write mutt > > the Bcc with the adress found in the From h

Re: BCC from the FROM header

On Sunday, 03 June at 08:29, Michael Wagner wrote: > I have a folder called 'privat' in which all the private mails from my 3 > accounts are collected. When I answer to a mail, I want to write mutt > the Bcc with the adress found in the From header, because I want my > answers in the

BCC from the FROM header

Hello folks, I have a folder called 'privat' in which all the private mails from my 3 accounts are collected. When I answer to a mail, I want to write mutt the Bcc with the adress found in the From header, because I want my answers in the same folder. I know folder-hook, but it only works

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

misconfiguration, and Mutt requires nothing if not attention to the > > documentation and configuration. I agree strongly with this point. Moreover, it's reasonable to presume that anyone subscribed to this list uses Mutt (at least some of the time), and as such have access to features that

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

On Fri, Apr 27, 2018 at 06:33:52AM +0200, Matthias Apitz wrote: > El día jueves, abril 26, 2018 a las 05:28:55p. m. -0500, Derek Martin > escribió: > > > On Wed, Apr 25, 2018 at 07:31:20PM +0200, Matthias Apitz wrote: > > > $ grep -i Mail-Followup-To ~/.muttrc > > > $ > > > > > > as I said, I

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

On Mon, Apr 30, 2018 at 05:27:26PM +1000, Erik Christiansen wrote: > Here, declares: "Mutt also supports the Mail-Followup-To header. > When you send a message to a list of recipients which includes one or > several subscribed mailing lists, and if the $followup_to option

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

> > However, if there is a strong majority of mutt-users subscribers that > agree with $followup_to defaulting to 'no', I'll make the change. Here, declares: "Mutt also supports the Mail-Followup-To header. When you send a message to a list of recipients which includes one or severa

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

On Fri, Apr 27, 2018 at 08:57:50AM -0700, Kevin J. McCarthy wrote: > > I always thought $followup_to was a pretty nice feature. While I > sympathize with Matthias, the mischief was the result of > misconfiguration, and Mutt requires nothing if not attention to the > documentation and

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

* Kevin J. McCarthy [04-27-18 11:58]: [...] > I always thought $followup_to was a pretty nice feature. While I > sympathize with Matthias, the mischief was the result of > misconfiguration, and Mutt requires nothing if not attention to the > documentation and configuration. > >

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

On Thu, Apr 26, 2018 at 08:50:35PM +, Mihai Lazarescu wrote: > > > On April 26, 2018 8:24:16 PM UTC, Ian Zimmerman wrote: > > On 2018-04-25 10:24, Will Yardley wrote: > > > > > Kind of thread drift, but I actually wonder if Mutt shouldn't move > > > away from

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

s the list manager, and that's what I call munging. > > I don't believe so. I have reply_goes_to_list set to 'Poster', which is > not supposed to add (or remove) any such header. yes, Mail-Followup-To, is set to list addr and Reply-To is empty. -- (paka)Patrick Shanahan

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

y_goes_to_list set to 'Poster', which is not supposed to add (or remove) any such header. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

On 2018-04-27 06:33, Matthias Apitz wrote: > Hmm, someone set Reply-To in the headers of your mail too. That was the list manager, and that's what I call munging. AIUI it was one of the reasons why Mail-Followup-To was invented, because Reply-To could not be trusted anymore. I feel it would be

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

El día jueves, abril 26, 2018 a las 05:28:55p. m. -0500, Derek Martin escribió: > On Wed, Apr 25, 2018 at 07:31:20PM +0200, Matthias Apitz wrote: > > $ grep -i Mail-Followup-To ~/.muttrc > > $ > > > > as I said, I do not set any Mail-Followup-To; and I think Reply-To: > > and From: is quite

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

t replies to go to a different address than the one in the From header. In most cases your From address should be the same as the address you receive mail at, and thus there's no reason to set reply-to. You can of course set it anyway, and usually it will have no effect; but if you do so it's possib

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

On April 26, 2018 8:24:16 PM UTC, Ian Zimmerman wrote: > On 2018-04-25 10:24, Will Yardley wrote: > > > Kind of thread drift, but I actually wonder if Mutt shouldn't move > > away from Mail-Followup-To, as it never became a standard, and is > not > > really adopted by

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

On 2018-04-25 10:24, Will Yardley wrote: > Kind of thread drift, but I actually wonder if Mutt shouldn't move > away from Mail-Followup-To, as it never became a standard, and is not > really adopted by (m)any other commonly used mail clients. It is supported by Gnus. I don't know of any others,

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

e in my case, things that > the user newer wanted and not even was aware of. If the user doesn't use 'lists' or 'subscribe' in the first place, I think the MFT header should not get set. I do agree that it's slightly confusing and took me a bit to understand the difference when I started

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

El día Wednesday, April 25, 2018 a las 08:23:37PM -0400, Patrick Shanahan escribió: > you might want to reconsider. you said *you* didn't make the setting, > that "mutt" was to blame. there really is no "blame". one must make the > settings to do what they wish and you didn't bother and now

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

I'm tired of such blames. I'm using mutt for more then 15 years, IIRC. And of course every day you learn something new or something I did wrong. But what you send is not help, but just blames. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 

Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)

* Matthias Apitz [04-25-18 17:20]: > El día miércoles, abril 25, 2018 a las 04:14:52p. m. -0400, Patrick Shanahan > escribió: > > > > Who adds this? mutt by its own? If so, based on what? > > > > > > you do, don't you have man pages for mutt and muttrc? mutt doesn't do > >

  1   2   3   4   5   6   7   8   9   10   >