Re: Best way to move large Maildir to another machine?
Thanks for the replies. On 26/11/20 10:38, Cameron Simpson put forth the proposition: > I'd expect rsync to be faster than scp, and personally I'd use "cd > the-mailddir; tar cf > - . | ssh remote 'cd remote-maildir; tar xf -'" which should be much > faster than either. Very interesting idea... I'll try it out tomorrow. Cheers, -- Dave Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come. --Friedrich Nietzsche
Re: Best way to move large Maildir to another machine?
On Wed, Nov 25, 2020 at 10:30:54PM +, Dave Woodfall wrote: > Hello all, > > I have a Maildir folder which I want to move to another machine: > about 830M with 29000 messages. > > Would just rsync'ing or scp'ing be OK? > > I'm asking because I noticed that either procmail or getmail puts the > hostname in the file names, and I wondered if this would cause > problems at the other end or not when I've setup getmail+procmail on > it? > > Renaming all the files is possible I guess, but would be a task. Although you don't need to rename these files, if you did (or if you wanted to), it isn't difficult. See my "mved" program which lets you rename multiple files/directories easily and safely: http://raf.org/mved https://github.com/raforg/mved Either of these commands would replace the hostname in all files in the current directory: mved '*oldhostname*' =newhostname= mved =oldhostname= =newhostname= The '=' is like '*' but you don't have to quote it from the shell. There are other programs that rename multiple files but they aren't generic enough, or they require the user to know Perl. cheers, raf
Re: mutt seems laggy to resume on v.2.x
On Thu, Nov 26, 2020 at 10:34:30AM +1100, Cameron Simpson wrote: Probably. I don't have a FreeBSD box to hand. Is yours a Raspberry? yup, rpi4 with 8GB Have you got ktrace and kdump? Less interactive, but IIRC the process is to ktrace your mutt command and kdump the resulting log file. I don't have it right this moment because when building the kernel it was one of the things I took out to streamline it. I'll recompile and get back with results. With my other tests, recompiling mutt with different header backends made no difference. I think you're right with the auto-sleep thing. Hopefully it can be turned off. Thanks all for your help. -- J. signature.asc Description: PGP signature
Re: Best way to move large Maildir to another machine?
On 25Nov2020 22:30, Dave Woodfall wrote: >I have a Maildir folder which I want to move to another machine: >about 830M with 29000 messages. > >Would just rsync'ing or scp'ing be OK? Yes. Use "scp -p" if you use scp, preserves permissions and timestamps (actually not very important unless you're following up with rsync to check). I'd expect rsync to be faster than scp, and personally I'd use "cd the-mailddir; tar cf - . | ssh remote 'cd remote-maildir; tar xf -'" which should be much faster than either. If the maildir is "active" I'd follow up with rsync afterwards, when it is idle, to catch any changes which may have occurred. >I'm asking because I noticed that either procmail or getmail puts the >hostname in the file names, and I wondered if this would cause >problems at the other end or not when I've setup getmail+procmail on >it? That will not be a problem. The hostname is just one of the values used to make a unique nonconflicting filename. It has no meaning afterwards. >Renaming all the files is possible I guess, but would be a task. And unnecessary. Cheers, Cameron Simpson
Re: mutt seems laggy to resume on v.2.x
On 25Nov2020 22:33, tech-lists wrote: >On Thu, Nov 26, 2020 at 09:01:03AM +1100, Cameron Simpson wrote: >>A way to check this would be to have another window open running: >> >> strace -p pid-of-idle-mutt-process >> >>Get that ready. Wait for idleness. Resume. See where it stalls. >> >>If that is hard to observe interactively, strace has options for >>including timestamps in the trace output, you could do the resume and >>then scroll back looking for the stall in the timestamps. > >Unfortunately strace (do you mean devel/strace) Probably. I don't have a FreeBSD box to hand. Is yours a Raspberry? >appears to be broken: > >root@rpi4:/usr/ports/devel/strace# make >===> strace-4.5.18_1 is marked as broken: Uses procfs-based process debugging. >*** Error code 1 > >Is there an equivalent tool? Have you got ktrace and kdump? Less interactive, but IIRC the process is to ktrace your mutt command and kdump the resulting log file. See this: https://www.unix.com/man-page/FreeBSD/1/ktrace/ Note that you can trace particular stuff with the -t option. Options "i" and "n" and "c" look promising for what I'm imagining is your problem (hard drive spun down, slow to spin up). You can attach ktrace to a running process with -p, so "ktrace -p pid-of-mutt". So you could: - start mutt, let it idle - ktrace -p pid-of-mutt - resume mutt, wait for it to wake up - stop the ktrace - use kdump on the ktrace,out file, see where mutt spent its time Cheers, Cameron Simpson
Re: mutt seems laggy to resume on v.2.x
On 25Nov2020 17:56, Patrick Shanahan wrote: >* tech-lists [11-25-20 17:55]: >> On Wed, Nov 25, 2020 at 05:43:21PM -0500, Patrick Shanahan wrote: >> > possibly reinstall strace. for my openSUSE Tumbleweed system I >> > show: strace-5.9-1.1.x86_64 >> > >> > your version is quite old and version number appear to reflect the kernel >> > version. what kernel are you running, 4.5.x ?? >> >> I'm using freebsd-current > >sorry, that is not a version, and I am not running freebsd. how would I >know what that equates to? It doesn't. FreeBSD is not a Linux based system, so its kernel version will bear no relationship to your system. I uses to use truss on Solaris and maybe dtrace will help on FreeBSD. I'll look around... Cheers, Cameron Simpson
Re: mutt seems laggy to resume on v.2.x
* tech-lists [11-25-20 17:55]: > Hi, > > On Wed, Nov 25, 2020 at 05:43:21PM -0500, Patrick Shanahan wrote: > > > possibly reinstall strace. for my openSUSE Tumbleweed system I show: > > strace-5.9-1.1.x86_64 > > > > your version is quite old and version number appear to reflect the kernel > > version. what kernel are you running, 4.5.x ?? > > I'm using freebsd-current sorry, that is not a version, and I am not running freebsd. how would I know what that equates to? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
Re: mutt seems laggy to resume on v.2.x
Hi, On Wed, Nov 25, 2020 at 05:43:21PM -0500, Patrick Shanahan wrote: possibly reinstall strace. for my openSUSE Tumbleweed system I show: strace-5.9-1.1.x86_64 your version is quite old and version number appear to reflect the kernel version. what kernel are you running, 4.5.x ?? I'm using freebsd-current -- J. signature.asc Description: PGP signature
Re: mutt seems laggy to resume on v.2.x
IIRC I just went with the ports/mail/mutt defaults. I selected ispell because I'm more used to the ispell interface. Now-a-days it's all aspell under the covers. On Wed, Nov 25, 2020 at 10:19:57PM +, tech-lists wrote: > Hello, > > On Wed, Nov 25, 2020 at 09:59:30AM -0600, Hokan wrote: > > >I am running a month-old FreeBSD-CURRENT on an RPI-4 (8GB) and could not > >replicate the problem. > > thanks for posting yr config. > > Your mutt is compiled just slightly differently: > > >hcache backend: Berkeley DB 5.3.28: (September 9, 2013) > > Is there a reason why you're using this hcache backend? > > different configure options: '--disable-autocrypt' '--without-sqlite3' > '--with-bdb=/usr/local' '--without-tokyocabinet' > > Compile options: > >ISPELL="/usr/local/bin/ispell" > > I'm going to try recompiling with options as you've set them. > Might try kyotocabinet too -- Hokan Bicyclist Sysadmin
Re: Best way to move large Maildir to another machine?
Hi! I've moved/renamed/backed up/restored Maildirs which contain files with the hostname in the file name and it really doesn't matter afaict. getmail, procmail, etc just want a way to construct a unique filename, so they use the hostname as part of it. Your mail reader shouldn't care what the files are named, since it should be parsing the message itself (including headers) to figure out the information to display. One caveat: Maildir uses the last parts of the file name to store flags like replied, flagged, and so on, so the file names *do* matter, just not in this context. HTH! - Chiraag -- ಚಿರಾಗ್ ನಟರಾಜ್ Pronouns: he/him/his 25/11/20 22:30 ನಲ್ಲಿ, Dave Woodfall ಬರೆದರು: > > Hello all, > > I have a Maildir folder which I want to move to another machine: > about 830M with 29000 messages. > > Would just rsync'ing or scp'ing be OK? > > I'm asking because I noticed that either procmail or getmail puts the > hostname in the file names, and I wondered if this would cause > problems at the other end or not when I've setup getmail+procmail on > it? > > Renaming all the files is possible I guess, but would be a task. > > -- > Dave > > Love is a snowmobile racing across the tundra and then suddenly it flips over, > pinning you underneath. At night, the ice weasels come. >--Friedrich Nietzsche publickey - mailinglist@chiraag.me - b0c8d720.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: mutt seems laggy to resume on v.2.x
* tech-lists [11-25-20 17:36]: > Hi, > > On Thu, Nov 26, 2020 at 09:01:03AM +1100, Cameron Simpson wrote: > > A way to check this would be to have another window open running: > > > >strace -p pid-of-idle-mutt-process > > > > Get that ready. Wait for idleness. Resume. See where it stalls. > > > > If that is hard to observe interactively, strace has options for > > including timestamps in the trace output, you could do the resume and > > then scroll back looking for the stall in the timestamps. > > Unfortunately strace (do you mean devel/strace) appears to be broken: > > root@rpi4:/usr/ports/devel/strace# make > ===> strace-4.5.18_1 is marked as broken: Uses procfs-based process > debugging. > *** Error code 1 > > Is there an equivalent tool? possibly reinstall strace. for my openSUSE Tumbleweed system I show: strace-5.9-1.1.x86_64 your version is quite old and version number appear to reflect the kernel version. what kernel are you running, 4.5.x ?? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
Best way to move large Maildir to another machine?
Hello all, I have a Maildir folder which I want to move to another machine: about 830M with 29000 messages. Would just rsync'ing or scp'ing be OK? I'm asking because I noticed that either procmail or getmail puts the hostname in the file names, and I wondered if this would cause problems at the other end or not when I've setup getmail+procmail on it? Renaming all the files is possible I guess, but would be a task. -- Dave Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come. --Friedrich Nietzsche
Re: mutt seems laggy to resume on v.2.x
Hi, On Thu, Nov 26, 2020 at 09:01:03AM +1100, Cameron Simpson wrote: A way to check this would be to have another window open running: strace -p pid-of-idle-mutt-process Get that ready. Wait for idleness. Resume. See where it stalls. If that is hard to observe interactively, strace has options for including timestamps in the trace output, you could do the resume and then scroll back looking for the stall in the timestamps. Unfortunately strace (do you mean devel/strace) appears to be broken: root@rpi4:/usr/ports/devel/strace# make ===> strace-4.5.18_1 is marked as broken: Uses procfs-based process debugging. *** Error code 1 Is there an equivalent tool? thanks, -- J. signature.asc Description: PGP signature
Re: mutt seems laggy to resume on v.2.x
Hello, On Wed, Nov 25, 2020 at 09:59:30AM -0600, Hokan wrote: I am running a month-old FreeBSD-CURRENT on an RPI-4 (8GB) and could not replicate the problem. thanks for posting yr config. Your mutt is compiled just slightly differently: hcache backend: Berkeley DB 5.3.28: (September 9, 2013) Is there a reason why you're using this hcache backend? different configure options: '--disable-autocrypt' '--without-sqlite3' '--with-bdb=/usr/local' '--without-tokyocabinet' Compile options: ISPELL="/usr/local/bin/ispell" I'm going to try recompiling with options as you've set them. Might try kyotocabinet too -- J. signature.asc Description: PGP signature
Re: mutt seems laggy to resume on v.2.x
On 25Nov2020 14:19, tech-lists wrote: >I'm finding mutt significantly more laggy to resume on later >versions (=>2.x) than say 1.5.21. > >Let's say there's the list of emails in a folder already selected. If >I use up or down arrow for example, it'll sit for 3-4 seconds doing >nothing and then move. But once moving, it's >as responsive as it's always been before. > >Then, say 5 minutes happen where nothing happens. Slow to move >around again. I'm using imaps. It's not having to re-authenticate, so >the connection isn't dropping. Ping times to the imap server are 77ms, >no packet loss. [...] >For context: >freebsd-current (all debugging has been turned off) >TMP is ~/tmp and is tmpfs (memory) mounted. >$HOME is usb3-mounted spinning rust. I don't know why version 2.x would be worse than 1.5.21 off hand. But... USB3-mounted spinning rust has a strong tendency to spin down when idle, it is usually also a physically slow variety of drive (if USB-powered - low power consumption). Do you use the header cache? That would involve local disc access to resume activity (looking up headers to present in the index, etc). A way to check this would be to have another window open running: strace -p pid-of-idle-mutt-process Get that ready. Wait for idleness. Resume. See where it stalls. If that is hard to observe interactively, strace has options for including timestamps in the trace output, you could do the resume and then scroll back looking for the stall in the timestamps. Cheers, Cameron Simpson
Re: mutt seems laggy to resume on v.2.x
I am running a month-old FreeBSD-CURRENT on an RPI-4 (8GB) and could not replicate the problem. Mutt 2.0.2 (2020-11-20) Copyright (C) 1996-2020 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: FreeBSD 13.0-CURRENT (arm64) ncurses: ncurses 6.2.20200215 (compiled with 6.2) libiconv: 1.16 libidn2: 2.3.0 (compiled with 2.3.0) hcache backend: Berkeley DB 5.3.28: (September 9, 2013) Compiler: FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673) Target: aarch64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin Configure options: '--disable-fcntl' '--with-ssl=/usr' '--with-docdir=/usr/local/share/doc/mutt' '--sysconfdir=/usr/local/etc' '--enable-external-dotlock' '--enable-pop' '--enable-imap' '--enable-compressed' '--enable-sidebar' '--disable-autocrypt' '--without-sqlite3' '--enable-debug' '--disable-flock' '--enable-gpgme' '--without-gss' '--with-bdb=/usr/local' '--without-kyotocabinet' '--enable-hcache' '--without-qdbm' '--without-gdbm' '--without-tokyocabinet' '--with-libiconv-prefix=/usr/local' '--with-idn2=/usr/local' '--enable-locales-fix' '--enable-nls' '--with-sasl=/usr/local' '--enable-smtp' '--prefix=/usr/local' '--localstatedir=/var' '--mandir=/usr/local/man' '--disable-silent-rules' '--infodir=/usr/local/share/info/' '--build=aarch64-portbld-freebsd13.0' 'build_alias=aarch64-portbld-freebsd13.0' 'CC=cc' 'CFLAGS=-O2 -pipe -fstack-protector-strong -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector-strong ' 'LIBS=' 'CPPFLAGS=' 'CPP=cpp' Compilation CFLAGS: -Wall -pedantic -Wno-long-long -O2 -pipe -fstack-protector-strong -fno-strict-aliasing 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_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="/usr/local/etc" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to . To report a bug, please contact the Mutt maintainers via gitlab: https://gitlab.com/muttmua/mutt/issues patch-1.5.0.ats.date_conditional.1 patch-1.5.6.cb.reverse_reply.2 patch-1.5.7.ust.maildir-mtime.2 patch-1.5.4.cd.ifdef.1 vvv.quote vvv.initials On Wed, Nov 25, 2020 at 02:19:38PM +, tech-lists wrote: > Hi, > > I'm finding mutt significantly more laggy to resume on later > versions (=>2.x) than say 1.5.21. > > Let's say there's the list of emails in a folder already > selected. If I use up or down arrow for example, it'll sit for > 3-4 seconds doing nothing and then move. But once moving, it's > as responsive as it's always been before. > > Then, say 5 minutes happen where nothing happens. Slow to move > around again. I'm using imaps. It's not having to re-authenticate, > so the connection isn't dropping. Ping times to the imap server > are 77ms, no packet loss. > > Is it my config? Maybe should revise it as it's not changed > significantly for more than a decade. What should I be looking for? > > For context: > freebsd-current (all debugging has been turned off) > TMP is ~/tmp and is tmpfs (memory) mounted. > $HOME is usb3-mounted spinning rust. > > % mutt -v > Mutt 2.0.2 (2020-11-20) > Copyright (C) 1996-2020 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: FreeBSD 13.0-CURRENT (arm64) > ncurses: ncurses 6.2.20200215 (compiled with 6.2) > libiconv: 1.16 > libidn2: 2.3.0 (compiled with 2.3.0) > hcache backend: tokyocabinet 1.4.48 > > Compiler: > FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git > llvmorg-11.0.0-0-g176249bd673) > Target: aarch64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin > > Configure options: '--disable-fcntl' '--with-ssl=/usr' > '--with-docdir=/usr/local/share/doc/mutt' '--sysconfdir=/usr/local/etc' > '--enable-external-dotlock' '--enable-pop' '--enable-imap' > '--enable-compressed' '--enable-sidebar' '--enable-autocrypt' > '--with-sqlite3=/usr/local' '--enable-debug' '--disable-flock' > '--enable-gpgme' '--without-gss'
Re: Is it possible to use send-hook to 'edit' a header
For a more generic solution that I just setup in my config file: 1. Use the following send-hook: send-hook ~l "set from='Name '" 2. Declare all of the mailing lists to be caught by the ~l parameter using lists: lists mutt-users@mutt.org gnupg-us...@gnupg.org Now, whenever I reply to a mailing list, my From address is set using the send-hook. Of course, this is only desirable if, in fact, you want the same hook run for all mailing lists (my case). Otherwise, you can use my previous solution, which uses the ~t limiter to specify the pattern of To addresses that the send-hook 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 the email you're _sending_). The slight downside is that you might need a from-address-based pattern if you regularly reply to individuals who sent the email (rather than sending the email to the mailing list), since this type of pattern won't catch that. In that case, simply change it to ~f, but keep in mind that it's the From address _of the email you're sending_, *not* of the received email (the one you're replying to). HTH! - Chiraag -- ಚಿರಾಗ್ ನಟರಾಜ್ Pronouns: he/him/his 25/11/20 13:46 ನಲ್ಲಿ, ಚಿರಾಗ್ ನಟರಾಜ್ ಬರೆದರು: > The way I did it for this list is: > > send-hook ~tmutt-us...@mutt.org "set from='ಚಿರಾಗ್ ನಟರಾಜ್ > '" > > You should be able to edit the mutt-users@mutt.org to be *@groups.io or > something (you may have to escape the asterisk?) and then use set from='Name > ' as the command to run. > > HTH! > > - 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 > > certain senders' addresses the requirement would be to have a > > send-hook match on "via groups.io" in the From: header and would then > > change to . > > > > It's a fairly easy sort of search/replace but I can't see any obvious > > way to implement it in mutt. > > > > It can be done for specific From: addresses by matching the address > > with a send-hook and using my_hdr to write a new From: (will that > > remove the orginal From: ?). However this would require a send-hook > > for every individual address. > > > > -- > > Chris Green publickey - mailinglist@chiraag.me - b0c8d720.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
mutt seems laggy to resume on v.2.x
Hi, I'm finding mutt significantly more laggy to resume on later versions (=>2.x) than say 1.5.21. Let's say there's the list of emails in a folder already selected. If I use up or down arrow for example, it'll sit for 3-4 seconds doing nothing and then move. But once moving, it's as responsive as it's always been before. Then, say 5 minutes happen where nothing happens. Slow to move around again. I'm using imaps. It's not having to re-authenticate, so the connection isn't dropping. Ping times to the imap server are 77ms, no packet loss. Is it my config? Maybe should revise it as it's not changed significantly for more than a decade. What should I be looking for? For context: freebsd-current (all debugging has been turned off) TMP is ~/tmp and is tmpfs (memory) mounted. $HOME is usb3-mounted spinning rust. % mutt -v Mutt 2.0.2 (2020-11-20) Copyright (C) 1996-2020 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: FreeBSD 13.0-CURRENT (arm64) ncurses: ncurses 6.2.20200215 (compiled with 6.2) libiconv: 1.16 libidn2: 2.3.0 (compiled with 2.3.0) hcache backend: tokyocabinet 1.4.48 Compiler: FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673) Target: aarch64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin Configure options: '--disable-fcntl' '--with-ssl=/usr' '--with-docdir=/usr/local/share/doc/mutt' '--sysconfdir=/usr/local/etc' '--enable-external-dotlock' '--enable-pop' '--enable-imap' '--enable-compressed' '--enable-sidebar' '--enable-autocrypt' '--with-sqlite3=/usr/local' '--enable-debug' '--disable-flock' '--enable-gpgme' '--without-gss' '--without-bdb' '--without-kyotocabinet' '--enable-hcache' '--without-qdbm' '--without-gdbm' '--with-tokyocabinet=/usr/local' '--with-libiconv-prefix=/usr/local' '--with-idn2=/usr/local' '--enable-locales-fix' '--enable-nls' '--with-sasl=/usr/local' '--enable-smtp' '--prefix=/usr/local' '--localstatedir=/var' '--mandir=/usr/local/man' '--disable-silent-rules' '--infodir=/usr/local/share/info/' '--build=aarch64-portbld-freebsd13.0' 'build_alias=aarch64-portbld-freebsd13.0' 'CC=cc' 'CFLAGS=-O2 -pipe -fstack-protector-strong -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector-strong ' 'LIBS=' 'CPPFLAGS=' 'CPP=cpp' Compilation CFLAGS: -Wall -pedantic -Wno-long-long -O2 -pipe -fstack-protector-strong -fno-strict-aliasing 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_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 SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/local/share/mutt" SYSCONFDIR="/usr/local/etc" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to . To report a bug, please contact the Mutt maintainers via gitlab: https://gitlab.com/muttmua/mutt/issues patch-1.5.0.ats.date_conditional.1 patch-1.5.6.cb.reverse_reply.2 patch-1.5.7.ust.maildir-mtime.2 patch-1.5.4.cd.ifdef.1 vvv.quote vvv.initials thanks, -- J. signature.asc Description: PGP signature
Re: Is it possible to use send-hook to 'edit' a header
The way I did it for this list is: send-hook ~tmutt-us...@mutt.org "set from='ಚಿರಾಗ್ ನಟರಾಜ್ '" You should be able to edit the mutt-users@mutt.org to be *@groups.io or something (you may have to escape the asterisk?) and then use set from='Name ' as the command to run. HTH! - 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 > certain senders' addresses the requirement would be to have a > send-hook match on "via groups.io" in the From: header and would then > change to . > > It's a fairly easy sort of search/replace but I can't see any obvious > way to implement it in mutt. > > It can be done for specific From: addresses by matching the address > with a send-hook and using my_hdr to write a new From: (will that > remove the orginal From: ?). However this would require a send-hook > for every individual address. > > -- > Chris Green publickey - mailinglist@chiraag.me - b0c8d720.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
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 From: header and would then change to . It's a fairly easy sort of search/replace but I can't see any obvious way to implement it in mutt. It can be done for specific From: addresses by matching the address with a send-hook and using my_hdr to write a new From: (will that remove the orginal From: ?). However this would require a send-hook for every individual address. -- Chris Green
