Re: Scheduling deferred sending of emails
On Sat, Jul 29, 2023 at 11:00:32AM +, Claus Assmann wrote: > Use a script as "sendmail" program for mutt which > - submits the mail but tells the MTA to only queue it, > - gets the info about the queued msg from the MTA when > it accepts the mail, > - schedules a queue run for that item at the desired time. > and make sure the MTA does not run the msg any earlier. Yes, this would be my preferred way to do it too. I'm an exim fan (sort of) and I'm sure it can be done with exim. Btw, I have an intermediate "fake MTA" in my setup anyway for security reasons. Normally exim is installed setuid root and world-executable, and the reason for the latter part is that it needs to act as the submission agent as well; if another simpler program takes over the submission role, exim can be mode 04754 with a dedicated group. -- Ian
Re: Want command line program to selectively delete emails
On Fri, Aug 04, 2023 at 10:56:18PM +0200, Marcus C. Gottwald wrote: >find ~/mail/folder1/cur/ -maxdepth 1 -type f -not -name '.*' \ > -mtime +30 \ > -not -name '*:2,*F*' \ > -delete > The conditions in the first line are generic, the other three > lines should match your example: received more than 30 full days > ago && not flagged => delete. I think an mtime test is not the same as "date received" test. You may have created the folder by recursive copy from somewhere else, just to take the most obvious problem. Some of us also love mutt's ability to modify messages after they're delivered (the E, & and # keys). I think for a true date received test, you have to look at the timestamp part of the filename. Or look at the message headers, but this would be much slower. -- Ian
Re: Want command line program to selectively delete emails
On Sun, Aug 06, 2023 at 04:04:34PM +0200, Marcus C. Gottwald wrote: > > I think for a true date received test, you have to look at the > > timestamp part of the filename. > Well, it looks like both mtime and timestamp-as-part-of-filename may > change when copying messages between Maildirs, at least when using > Mutt and a local filesystem. So if mtimes do not reflect the desired > timestamp, neither might timestamp-as-part-of-filename. I was thinking of just using cp and friends, and yes I have done that to move around my maildirs. I'm curious if mutt preserves the mtime when doing the mutating operations I mentioned ie. rethreading or editing after the fact. Especially in the case of editing, I have serious doubts that mtime is preserved. But maybe mutt also creates a fresh message in this case, my memory is foggy. I'm also curious what other programs look at the mtime to determine time delivered. I mean real programs, not your hand written scripts ;-) Friendly, -- Ian
Re: Terminal redraw issues / isync launchctl job in macOS 13.5
On Mon, Aug 07, 2023 at 06:25:35PM +0200, Jan Eden via Mutt-users wrote: > > Others suggested I should switch to iTerm2 which doesn't seem > > to have the problem. > Thanks for the suggestion – I will try iTerm2 then. I recommend alacritty. iterm2 is too complex and when I reported a security bug I was ignored. -- Ian
Re: Terminal redraw issues / isync launchctl job in macOS 13.5
On Wed, Aug 09, 2023 at 07:47:48AM +0200, Jan Eden via Mutt-users wrote: > Unfortunately, the current version of alacritty is not notarized – > and iTerm2 exhibits the same redraw issues as the macOS terminal. By "notarized", you mean that Mac refuses to run it because it's not by a "recognized developer"? I get that freeking error with pretty much every app I install from homebrew casks, and override it. I know that you may not be able to do the same if, for example, you use the Mac for $DAYJOB. I had similar, though milder, requirements. -- Ian
Re: DKIM fails depending on Content-Transfer-Encoding
On Wed, Sep 06, 2023 at 04:28:46PM +0200, f...@igh.de wrote: > works perfectly if the subject contains any non-ASCII characters. I think this case is not relevant, because any non-ascii characters in the Subject are converted to use the RFC-2047 scheme, I guess already in mutt. -- Ian
Re: DKIM fails depending on Content-Transfer-Encoding
On Thu, Sep 07, 2023 at 10:31:53AM +1000, raf via Mutt-users wrote: > Hi, This has come up recently in the Postfix mailing list. MTAs can > convert 8bit messages when sending to another MTA that doesn't > advertise that it can accept 8bit. If the DKIM signing happens > before the conversion, then subsequent DKIM checks will fail. Work > is being done in Postfix to address this. I don't know about other > MTAs. It seems unlikely that there are any MTAs that can't accept > 8bit messages, but perhaps there are some that are misconfigured and > don't advertise the fact to other MTAs. My own MTA is configured (not *mis*configured) like that, because I prefer SMTP as it was originally specified :) But I don't block incoming messages based on DKIM failure. -- Ian
Re: ^M line endings
On Fri, Oct 20, 2023 at 12:43:42PM +0200, Ralf Hildebrandt via Mutt-users wrote: > I'm getting a few mails which use "^M" line endings, which mutt > seems to ignore when displaying the body of the email. > How can I make mutt properly display the mail. My immediate reaction is you'll need an external filter like maybe tofrodos, although I don't know if tofrodos specifically can handle CR only input -- as opposed to CRLF. -- Ian
Re: Mutt showing ? in place of space
On Sat, Mar 30, 2024 at 09:21:53AM -0400, Derek Martin wrote: > > "Programs in the OpenBSD base system ignore the locale except for > > the character encoding..." > Mutt is not part of the "base system" so the limitation on locale > should not apply to it, and "except for the character encoding" > absolutely SHOULD apply, since that is specifically what is at issue > in your case. In my various attempts to try and learn more about the *BSDs, which happen periodically when the sky seems to be falling on Linux, I found that this type of issue is really tricky because one has to be sure to *build* against the packaged (i.e. non-base) libraries, including cases like libncurses. IIRC this is far from automatic, some packages as shipped link with the base ncurses. One has to inspect the package build. The same is true for homebrew and linuxbrew. -- Ian
Re: Question about message id
On Sun, Apr 07, 2024 at 01:19:09PM +, Ебрашка wrote: > Question, what should I write in .muttrc to make my outgoing mails > have the same beautiful message-ID as Yandex mail? Talk about bikeshedding :-) -- Ian
Re: Question about message id
On Thu, Apr 11, 2024 at 01:13:52PM +1000, raf via Mutt-users wrote: > > > Question, what should I write in .muttrc to make my outgoing > > > mails have the same beautiful message-ID as Yandex mail? > > The unfathomable thing about this question is why you (or anyone) > > should care in the slightest what your message ID looks like. > > It's an esoteric detail about e-mail transfer, the specific > > contents of which have no value to users, who in most cases won't > > even ever see the message ID, since most mail clients hide that > > detail from you by default. You have no practical reason to care > > what it is as long as everything is working correctly. It's > > literally not for you--it's for your MUA software. > The link to a kernel mailing list message that was provided earlier > in this discussion said that the choice to use base64 results in the > possibility of / characters being included in the message id which > causes problems for their archived messages accessible via a web > browser. So it seems that there is a reason to care about this. I believe it has to be a *syntactically* valid email address, according to the RFC. So, for example, an all-alphabetical random string would fail, because it'd lack a "@". > Although one could argue that the mailing list archiving system > should accept the responsibility of munging message ids to suit its > own needs. I've certainly seen mailing list archives on the web that > did munge the message id (but to replace @ characters, I think). I myself see not much wrong with a mailing list doing that, but: - others seem to feel differently, that modifying the msgid once a valid one has been generated by a MUA is gauche. And I understand that it makes some things slightly harder, especially if you use fcc or similar feature in other MUAs. - if the mailing list does mess with msgid, it absolutely must do it consistently for all copies of the message. Not like the mailman managed GNU lists where the msgid was (or still is?) munged if and only if the message was crossing a mail / news boundary. I stopped following the GNU lists because of that and I never went back. -- Ian
Re: Can't sign if I sign
On Sat, Apr 13, 2024 at 11:30:55AM +0200, Laura Orvokki Kursula via Mutt-users wrote: > > > I have encountered a strange problem setting up mutt: when I > > > attach a signature block to my e-mail using `$signature', my PGP > > > signature is, according to mutt, invalid. E-mails without > > > signature blocks yield valid PGP signatures. If I go back and > > > replace the automatic signature with something else, the PGP > > > signature checks out too. Is this a known issue? Is there > > > something I can do about it? > After some more testing, I figured out this issue had nothing at all > to do with signature blocks, or mutt. The culprit was the silly > `X-Clacks-Overhead' header I had configured postfix to add ages > ago. How I came to think it had a correlation with whether or not I > use a `$signature' remains a mystery; my bet is on a lack of sleep. But that is even odder. GPG signatures don't cover headers. Is it possible that your postfix bit was in fact added to the body instead? -- Ian
Re: sending automated GPG signed mails from batch job
On Tue, May 21, 2024 at 05:57:00PM GMT, Matthias Apitz wrote: > The problem with any automation, anyway if with GnuPG or not, is how > to enter the passphrase or PIN to get access to the private key. Does the gpg-agent help with that? It is supposed to, I think. -- Ian
Re: Locating mutt logs
On Mon, Jul 15, 2024 at 11:51:19PM GMT, Peter Flynn wrote: > I installed mutt 1.13.2 from the system repos on Mint 20.3 in order > to be able to force some wayward messages into the threads where > they belong. > That works fine on this address, so I have been trying to add more > of my accounts on various other servers, but some of them clearly > try to connect, but immediately claim "Login failed" with no other > information, which is not useful. It may help to try connecting with a straight command line program such as fetchmail. -- Ian
set From when replying
I'm sure this has been asked before, and it is even likely that at one time I knew the answer. But I'm getting old, and the world is enshittifying at a pace that makes me lose my mind :( So; I need to set the From when replying to the address which the original message was To. More precisely, and this is important, I need to set the *from* *variable*, i.e. a my_hdr command is not enough. My current configuration already inserts the correct From header, but leaves the variable empty, with unsatisfactory results (because I use the variable for another setting later in the config). -- Ian
Re: set From when replying
On Wed, Jul 17, 2024 at 01:58:29PM GMT, Will Yardley wrote: > > So; I need to set the From when replying to the address which the > > original message was To. > Does setting $reverse_name true and defining a regex in $alternates > to match the address pattern(s) work for you? I don't think it would; according to the documentation, the effect is to override the setting of "from" in some circumstances, not to actually _change_ it (temporarily or not). Anyways, I found a work-around. The set of addresses I want to use in this way is finite, and I already generate the part of my .muttrc where they are relevant with a script. So I told the script to generate another line per address, namely a reply-hook with a "~t $ADDRESS" match and "set from=$ADDRESS" as the payload. -- Ian
send-hook when forwarding
Apparently send-hook is not effective when forwarding with the "f" user interface. Is this intentional, a bug, or a missing feature that could be added? -- Ian
Re: Newbie Help for multiple signatures
On Sat, Jul 20, 2024 at 08:55:24AM GMT, MN Repair wrote: > Using Mutt 1.7.2. My manual stops at chapter 10. I need basic help > to get started once. Mind sharing chapter 14 ? The header of your mail says: User-Agent: NeoMutt/20170113 (1.7.2) which explains the difference, and strictly speaking it means that your question is out of scope here (AFAIK neomutt has its own mailing list stable). But, as a neomutt user myself, I can point you: https://neomutt.org/guide/configuration.html#lists This document covers the current version but AFAIK this area has not changed in a long while, at least from a user POV. I think this is a case where a search engine (e.g. dukgo) would've helped. -- Ian
Re: Newbie Help for multiple signatures
On Sat, Jul 20, 2024 at 04:09:20PM GMT, Kurt Hackenberg wrote:
> > https://neomutt.org/guide/configuration.html#lists
> It might not help. MN Repair earlier said this:
> > I do not have internet access. My email service is a 3rd party
> > private APN. So please exclude links in your answers.
Mea culpa. Here's the section I linked:
14. Mailing Lists
Usage:
lists [ -group name ...] regex [ regex ...]
unlists { * | regex ... }
subscribe [ -group name ...] regex [ regex ...]
unsubscribe { * | regex ... }
NeoMutt has a few nice features for handling mailing lists. In order
to take advantage of them, you must specify which addresses belong
to mailing lists, and which mailing lists you are subscribed
to. NeoMutt also has limited support for auto-detecting mailing
lists: it supports parsing mailto: links in the common List-Post:
header which has the same effect as specifying the list address via
the lists command (except the group feature). Once you have done
this, the function will work for all known
lists. Additionally, when you send a message to a known list and
$followup_to is set, NeoMutt will add a Mail-Followup-To header. For
unsubscribed lists, this will include your personal address,
ensuring you receive a copy of replies. For subscribed mailing
lists, the header will not, telling other users' mail user agents
not to send copies of replies to your personal address.
Note
The Mail-Followup-To header is a non-standard extension which is not
supported by all mail user agents. Adding it is not bullet-proof
against receiving personal CCs of list messages. Also note that the
generation of the Mail-Followup-To header is controlled by the
$followup_to configuration variable since it's common practice on
some mailing lists to send Cc upon replies (which is more a group-
than a list-reply).
More precisely, NeoMutt maintains lists of regular expressions for
the addresses of known and subscribed mailing lists. Every
subscribed mailing list is known. To mark a mailing list as known,
use the list command. To mark it as subscribed, use subscribe .
You can use regular expressions with both commands. To mark all
messages sent to a specific bug report's address on Debian's bug
tracking system as list mail, for instance, you could say
subscribe [0-9]+.*@bugs.debian.org
as it's often sufficient to just give a portion of the list's e-mail address.
Specify as much of the address as you need to to remove
ambiguity. For example, if you've subscribed to the NeoMutt mailing
list, you will receive mail addressed to
neomutt-us...@neomutt.org. So, to tell NeoMutt that this is a
mailing list, you could add lists neomutt-users@ to your
initialization file. To tell NeoMutt that you are subscribed to it,
add subscribe neomutt-users to your initialization file instead. If
you also happen to get mail from someone whose address is
neomutt-us...@example.com, you could use lists
^neomutt-users@neomutt\\.org$ or subscribe
^neomutt-users@neomutt\\.org$ to match only mail from the actual
list.
The -group flag adds all of the subsequent regular expressions to
the named address group in addition to adding to the specified
address list.
The “unlists” command is used to remove a token from the list of
known and subscribed mailing-lists. Use “unlists *” to remove all
tokens.
To remove a mailing list from the list of subscribed mailing lists,
but keep it on the list of known mailing lists, use unsubscribe .
--
Ian
Re: bouncing email and "from" address
On Wed, Jul 24, 2024 at 09:51:45AM GMT, Will Yardley wrote: > You can also add set use_envelope_from to make sure that value is > used for the envelope-sender as well as the header sender. Bounces in the SMTP sense should have an empty envelope sender, but I guess that's not what we're talking about here. -- Ian
Re: Auto jump to next mailbox from pager
On Mon, Dec 30, 2024 at 11:35:42PM +, Christian Ebert wrote: > > is there a way to make the command which moves to the next new or > > unread message in the pager (bound to Tab key in the pager keymap) > > go to the next mailbox with new messages (or unread, but that's > > not too important) when there are no more in the current mailbox? > Not exactly what you want, but did you try the next-unread-mailbox > function? Hmmm. I knew there was *some* command like that, I did not remember it or how to find it this time. Thank you. However, it is listed as an available (not actual) binding in index mode. Would it work to bind it in pager mode? As I wrote in the other subthread: the whole point of this question is that I want to avoid dropping into index mode when I run out of new and / or unread messages in the current mailbox, and jump straight to reading the first interesting message in the next mailbox that contains one. -- Ian
Re: Parametrize shell escape command
On Tue, Dec 31, 2024 at 09:54:06AM +0800, Kevin J. McCarthy wrote: > > for my next mutt tweak, my goal is to set up a macro key binding > > which will go in the pager keymap and, as its main job, will > > execute a . The part which -- as far as I can see -- > > is nontrivial: I need to pass the name of the current folder as an > > argument to the executed script. > > It is easy enough to set up a series of folder-hook mutt config > > commands so that the name ends up in a user mutt variable, say > > $my_folder_name. The seeming difficulty is in exporting this > > value to the external environment (in the precise Unix sense of > > this term). So far, any way I've thought of doing this turned out > > to only "beg the question". > The safest way might be to just use an environment variable > instead. Then, you can deal with parameter quoting issues properly > in your script, in a way that Mutt can't. > folder-hook . 'set my_mailbox=$visual;setenv MYMAILBOX $visual' Ta-daa !! I have not known about setenv. Thanks! -- Ian
Parametrize shell escape command
Dear list, for my next mutt tweak, my goal is to set up a macro key binding which will go in the pager keymap and, as its main job, will execute a . The part which -- as far as I can see -- is nontrivial: I need to pass the name of the current folder as an argument to the executed script. It is easy enough to set up a series of folder-hook mutt config commands so that the name ends up in a user mutt variable, say $my_folder_name. The seeming difficulty is in exporting this value to the external environment (in the precise Unix sense of this term). So far, any way I've thought of doing this turned out to only "beg the question". If it matters, I only use mutt locally and only on Maildir folders, so a folder name is always just the name of a subdirectory inside the directory named by $folder. -- Ian
Re: How to filter/limit for syntactically invalid From: line?
On Mon, Feb 03, 2025 at 09:08:46AM -0500, Ofer Inbar wrote: > From: a.org" > Probably because of the unbalanced quoting, these show up in my mutt > index as being from "@" - just the @ character in the sender column. > What search expression can I use in / or l(imit) or similar > commands, to match messages with a From: header like this? If I try > to look for any other contents of the From: header line, these > messages don't match. For example, if I do ~fa or ~fno-reply I > get _other_ messages that have those strings in their From:, but not > the message with the From: line I showed above. And of course ~f@ > matches everything. The first thing I'd try: ~f'^@$' -- Ian
Re: Refreshing pager index lines
On Wed, Feb 05, 2025 at 03:48:12PM +0100, dm1...@gmail.com wrote: > Is it possible to refresh the pager index (set with > $pager_index_lines) while in the pager, so that it shows new > messages since I have switched to the pager? Careful what you wish for: https://github.com/neomutt/neomutt/issues/4453 -- Ian
Auto jump to next mailbox from pager
Dear list, is there a way to make the command which moves to the next new or unread message in the pager (bound to Tab key in the pager keymap) go to the next mailbox with new messages (or unread, but that's not too important) when there are no more in the current mailbox? Right now it prints "No unread messages" and drops back to the index. I feel like I had this working at some point but things are beginning to blur, and I may be confusing it with slrn or something. -- Ian
Re: Two copies of email when cc-ed in mailing lists
On Thu, Dec 05, 2024 at 12:43:12PM -0500, Kurt Hackenberg wrote: > I guess what matters is what mass-market mail readers do. I guess > they would be Microsoft Outlook, Apple Mail (Mac), the iPhone mail > reader, and the Android app named "Gmail". What do they do? Gmail definitely lets you select between Reply and Reply All, and it respects Reply-To as far as I can tell. I never use it to read lists so I can't say if it does anything beyond -- if it modifies its behavior in that case, or if it show any additional UI. -- Ian
send-hook and aliases
On Wed, Feb 12, 2025 at 11:34:11AM -0500, Jon LaBadie wrote: > While composing a message (in vi) I add the alias name > to the Bcc: line and also set the Fcc: line to a mailbox > dedicated to the club's messges (i.e. "=club"). > I regularly forget to make the two additions so I thought I'd create > send-hooks for them. No problem for the Fcc: but I've not been able > to set the Bcc: line to an alias. Can you post an exact example of the send-hook command that seems to fail? Maybe change names to protect the guilty. -- Ian
send-hook and aliases
On Fri, Feb 14, 2025 at 09:52:12AM -0800, googly.negotiator...@aceecat.org wrote: > I don't have a pure mutt answer. Yet another suggestion: set `sendmail' variable to a script that inspects the destination address arguments and expands if necessary before calling the real sendmail or what have you. -- Ian
ignore * puzzle
On Wed, Feb 12, 2025 at 11:43:12AM -0500, Jude DaShiell wrote: > Why does ignore * not ignore User-Agent in mail messages when > reading? Do you have an unignore command somewhere after the ignore? It doesn't have to be for the exact string, I think the matching is by substring. So for example having "unignore Agent" would do it. -- Ian
send-hook and aliases
On Fri, Feb 14, 2025 at 01:23:17AM -0500, Jon LaBadie wrote: > alias partbox =part > send-hook 'pddb...@labadie.us'my_hdr Fcc: partbox > "partbox" does not get replaced with "=part". > While I do not need an alias for Fcc:, I do for Bcc:. > My alias looks like: > alias dbpart \ > "Andy Griffin" <96grif...@gmail.com>, \ > <100+ more lines like above> > "Vivian Leigh" > The corresponding send-hook that DOES NOT work would be: > send-hook 'pddb...@labadie.us'my_hdr Bcc: dbpart > The Bcc: line in my vi compose session is blank (i.e. only > the "Bcc: " is present). > NOTE, if I manually edit the Bcc: line and add the alias "dbpart", > the alias is substituted upon exiting vi and the 100+ addresses are > present in the "ask send" screen of mutt. It is this manual edit > requirement that I often forget and would like to replace with an > automated technique. I see, it looks like mutt doesn't expand aliases when processing my_hdr commands. It makes sense actually -- my_hdr can be any header at all, not necessarily relating to addresses. I don't have a pure mutt answer. I use emacs for editor, and if it were me, I would just write some elisp to execute automatically when opening a file that can be identified as a mutt message being composed. In fact I already have some elisp code like that, even though it doesn't modify the message, for now. Another possibility, depending on your sendmail / smtp setup and how much control you have over it: you could do the alias processing in the MTA, i.e. have an entry in /etc/aliases, or make a fake user and put the expansion in the ~/.forward file of that user. -- Ian
DKIM signature rejected
Sorry for the delay in replying. In light of yesterday's CVE
announcement I thought it might not be a good idea to advertise I'm
running exim until I patched it.
On Thu, Feb 20, 2025 at 06:06:59PM +0100, Matthias Apitz wrote:
> > > This email has a DKIM signature on the List- headers of the email,
> > > indicating that it is not allowed to pass this email on through a
> > > mailinglist.
> > The DKIM signature header you quote shows that you're signing over the
> > List-* headers. You -- or your SMTP server -- should not do that.
> > If you can't change that, you could try a public remailer of some sort.
> > Btw, I had exactly this problem with the postgresql-general mailing
> > list too. But I run my own mail server, so the fix was easy.
> Thanks very much for that explanation. I've access to the DNS
> configuration of my zone unixarea.de, where as I read such configurations
> must be done, but I don't know how. Please share how you have fixed
> this.
DNS stores the key, but if signing is done at all and which headers
are covered is a config item for the MTA -- in my case, exim. When I wrote
my reply to you I thought that back then I'd tweaked the list of signed
headers, but as it turns out I'd rather disabled signing completely for
messages going to lists:
remote_smtp:
driver = smtp
interface = <; MX6 ; MX4
max_rcpt = 1
return_path = ${acl{acl_sub_retpath}}
dkim_domain = $qualify_domain
# don't sign messages sent as aliases, those go mostly to lists
dkim_selector = ${if def:acl_m_sender_alias {} {rsa}}
dkim_private_key = SITECONFDIR/dkim-private/$dkim_selector
dkim_sign_headers = DKIM_NONLIST_HEADERS
hosts_avoid_pipelining = *
# this prepends X-Forwarded-For header if necessary
transport_filter = /usr/bin/env EXIM_LOCAL_RCPT=$acl_m_local_rcpt \
SITECONFDIR/smtp-transport-filter
--
Ian
DKIM signature rejected
On Sat, Feb 22, 2025 at 01:06:16PM +0100, Matthias Apitz wrote: > The following bug has been logged on the website: > i.e. the header lines of List-* are part of the DKIM signed lines. > I can't change this, as the signing is done by the MTA of 1blu.de. I > raised a ticket there, but without any luck until now. > On the other hand, the RFC 6576 explicitly allows this, see the > chapter > A Forwarder that does not modify the body or signed header fields > of a message is likely to maintain the validity of the existing > signature. It also could choose to add its own signature to the > message. ... I don't know specifically about the postgres list ATM, but 90% of lists nowadays do modify the body *and* the Subject header which is usually signed. The mutt list is one of the 10% exceptions. I agree that it is a bug, but then so is the very existence of DKIM. ;-) -- Ian
DKIM signature rejected
On Thu, Feb 20, 2025 at 10:50:52AM +0100, Matthias Apitz wrote: > I've got a reject of an email to a public PostgreSQL mailing list > due to an issue with my DKIM signature. Attached below. I've sent a > test email to my company mailbox to see my resulting DKIM > signature. It's: > What could be wrong with this and how do I fix this. mutt is sending > the mail to the SMTP server of my provider 1blu, i.e. I have in > ~/.muttrc: Just read the reply carefully: > This email has a DKIM signature on the List- headers of the email, > indicating that it is not allowed to pass this email on through a > mailinglist. The DKIM signature header you quote shows that you're signing over the List-* headers. You -- or your SMTP server -- should not do that. If you can't change that, you could try a public remailer of some sort. Btw, I had exactly this problem with the postgresql-general mailing list too. But I run my own mail server, so the fix was easy. -- Ian
changing 'From' and list address in .muttrc
On Mon, Mar 24, 2025 at 10:04:13AM -0500, mikemcclain...@att.net wrote: > email addresses are *.att.net changing 'from' and > 'envelope_from_address' in .muttrc breaks email sending since mutt > insists that those must agree with 'smtp_url'. This doesn't sound right. mutt should not care, it's just an MUA. What is the result you get when they don't "agree"? It's much more likely that the smtp server itself has a policy against masquerading the envelope sender address. -- Ian
