On Thu, May 25, 2023 at 10:24:52AM +0200, Eike Rathke wrote:
> >Semantically, the angle bracket characters are not part of the
> >msg-id; the msg-id is what is contained between the two angle bracket
> >characters.
>
> *Semantically*
> MUAs don't interpret semantics of header fields.
On Wed, May 24, 2023 at 07:54:32PM +0200, Ludolf Holzheid wrote:
> From RFC 5322: "The message identifier (msg-id) syntax is a limited
> version of the addr-spec construct enclosed in the
> angle bracket characters, "<" and ">"."
> That is, the less-than and greater
On Thu, Apr 13, 2023 at 05:05:31PM -0400, Craig Gallek wrote:
> I've managed to get this to work with gmail:
> https://gitlab.com/muttmua/mutt/-/blob/master/contrib/mutt_oauth2.py.README#L85
I have used the mutt_oauth2.py script to authenticate against an institutional
office365 account over IMAP
On Thu, Apr 13, 2023 at 01:59:56PM +0200, Sébastien Hinderer wrote:
> I am unfortunate enough to have to use an Office365 e-mail account.
> I don't know how to proceed from here. I really would like PLAIN to work
> because the only other mechanism supported is XAUTH2, which feels like a
> hell.
T
On Thu, Jul 22, 2021 at 12:11:17PM +0200, Vincent Lefevre wrote:
> I actually think that the compiler should warn in every case,
> but isn't able to detect all potential issues. The strfcpy
> definition seems wrong:
>
> # define strfcpy(A,B,C) strncpy (A,B,C), *(A+(C)-1)=0
>
> If A and B are buff
On Thu, Nov 12, 2020 at 09:22:45AM -0600, Derek Martin wrote:
> One point that is not clear to me is, the sigaction manpage explicitly
> calls out execve, rather than the whole exec family. It seems to
> suggest that execvp (which is what mutt is using to spawn the sendmail
> process) doesn't do t
On Sun, Jul 05, 2020 at 05:57:56PM -0700, Kevin J. McCarthy wrote:
> Yes, that's right. The indicator overwrites the item's color.
I personally would welcome a setting that allows the indicator not to
overwrite the item's colour. (I would probably set its attribute to
'reverse'.)
imc
On Mon, May 25, 2020 at 04:24:41PM +0200, Oswald Buddenhagen wrote:
> why not do something proper and use getentropy() instead?
It's been previously suggested on here that a mail client shouldn't
consume entropy from the system each time it starts, because other
more important processes may want i
On Tue, Apr 21, 2020 at 11:16:03PM +0200, Vincent Lefevre wrote:
> This is a user-side problem. Users should make sure that their
> hostname setting is unique (possibly with a very high probability,
> assuming no attacks). See below.
No. The hostname is what goes after the @ in your default email
On Mon, Apr 20, 2020 at 07:08:07PM +0200, Gero Treuner wrote:
> The concern is that the inputs based on local and/or private information
> can be leaked. To achieve this the search space must be big enough.
[heavily snipped, of course]
> We need data which is unrelated to the email but - to be dete
On Fri, Nov 02, 2018 at 10:08:30AM -0700, Kevin J. McCarthy wrote:
> With these you answer "yes" to stop:
> abort_noattach
> abort_nosubject
> abort_unmodified
> postpone
The postpone question is special because both answers stop.
In fact, if you quit accidentally and get asked the question
"Postp
On Wed, Aug 03, 2016 at 02:58:51PM +0200, Vincent Lefevre wrote:
> And if it is not possible to store the message anywhere in a safe
> location, then with the "store first" method, this would mean that
> it is not possible to send the message, which can be even worse.
Not really. If you really wa
On Wed, Jul 27, 2016 at 10:40:22PM -0500, Derek Martin wrote:
> On Wed, Jul 27, 2016 at 03:43:40PM +0100, Ian Collier wrote:
> > On Wed, Jul 27, 2016 at 02:46:18AM +0200, Vincent Lefevre wrote:
> > > Mutt should store the message to the Sent folder *after* running
> >
On Wed, Jul 27, 2016 at 02:46:18AM +0200, Vincent Lefevre wrote:
> Mutt should store the message to the Sent folder *after* running
> sendmail and *only* if sendmail returned with a zero exit status.
What happens if mutt is unable to store the message because the IMAP
server is down or the partiti
On Tue, Mar 08, 2016 at 11:53:03AM -0600, Derek Martin wrote:
> Yeah, looked into this for a minute, and determined it's atrocious.
> Should lead to mail store corruption unless you're only using maildir.
> The fact that Mutt isn't multithreaded is not interesting; the fact
> that multiple processe
On Fri, Jan 15, 2016 at 03:12:14PM +0100, Vincent Lefevre wrote:
> However, not all keys have a terminfo name. This means that you may be
> forced to use ";" in a key sequence for a binding.
My opinion is that ';' is not the problem - it's that curses is
returning so mutt never even sees the ';'.
On Thu, Jan 14, 2016 at 02:10:04PM -0800, Jeffery Small wrote:
> Ian Collier writes:
> >To be sure, open Mutt and type :exec what-key (press return and it
> >should reply "Enter keys (^G to abort):")
> One more question: How do you exit from the :exec mode and is the
On Thu, Jan 14, 2016 at 02:14:37AM -0800, Jeffery Small wrote:
> I have been running mutt on a Solaris system for years. I am now
> transitioning to a Ubuntu machine. I am using the same Sun Type 6 keyboard
> on both machines, however, on the new system there are some escape
> sequences issued by
On Tue, Oct 13, 2015 at 01:51:31PM -0500, David Champion wrote:
> The return from python's os.system is not the same as the exit status.
> You need os.WEXITSTATUS(os.system(command)), which should be 0, or
> success.
Although this is system-dependent, one popular implementation has:
#define __WEX
On Fri, Apr 26, 2013 at 02:17:49PM -0500, Derek Martin wrote:
> Using /dev/urandom on systems that have it isn't without its own
> problems... if your system doesn't have enough entropy, reading from
> /dev/urandom will block until it does.
On systems with a Linux kernel, /dev/urandom does not blo
On Thu, Apr 25, 2013 at 11:57:24PM -0500, Derek Martin wrote:
> The whole point of
> this subthread is that choosing not to rely on the system-provided
> library routines is folly. You can't provide anything better
> portably--your system libraries w
> 1) copy attached file to file
> 2) open the file with mutt -f
> 3) search the folder ('/' command) or apply a limit ('l' command) using
> the pattern "~b asdf" (without the quotes of course) for the pattern. You
> need to search the body of the email but it doesn't matter if searching
>
I'm not supporting any particular side either, but it would be nice if
it were possible to unauto_view types such as text/html - i.e., I don't
ever want to see the source of an HTML attachment unless I press T (view
as text) in the attachments menu. (I tried, it doesn't work.)
On the other side,
On Mon, Nov 10, 2008 at 08:55:06AM -0800, Gary Johnson wrote:
> I tried the following three methods of specifying my from address.
> 1.
> [EMAIL PROTECTED] echo test | mutt -s test garyjohn
You would need to put the env setting on the right-hand side of the
pipe for that to work.
imc
On Wed, Oct 29, 2008 at 02:55:35PM +1100, Cameron Simpson wrote:
> So, -a: single filename, -g: multiple names but still with the shell
> doing the globbing.
+1 (and, actually, to the rest of the email which I trimmed for neatness).
imc
On Fri, Sep 28, 2007 at 11:12:07AM -0500, Kyle Wheeler wrote:
> On Friday, September 28 at 12:59 PM, quoth Ian Collier:
> >A particular email has the headers attached below. If I start mutt
> >(with no rc file just to make things consistent: "mutt -n -F /dev/null")
&g
Apologies if this is a mutt-users issue, but it looks like mutt is being
inconsistent in how it determines whether a message came from a mailing
list.
Mutt version: Mutt 1.5.14 (2007-02-12) [mutt-1.5.14-checkmboxsize.patch]
as packaged in Fedora 7. But I have verified this with a copy compiled
fr
On Tue, Sep 11, 2007 at 08:53:27AM -0400, Patrick Shanahan wrote:
> *default* is the definition of mutt's color table, not xterm's, and
> mutt prevails.
I don't know where mutt gets its ideas of default colours from, and I
don't mind what the defaults are, but the point is this: if you start
it up
On Tue, Sep 11, 2007 at 08:31:17AM -0400, Patrick Shanahan wrote:
> * Ian Collier <[EMAIL PROTECTED]> [09-11-07 06:29]:
> > I'm using mutt-1.5.14-4 as seen on Fedora 7, compiled with ncurses 5.6,
> > in an xterm (X.Org 6.8.99.903(227)) with default colours (i.e. in norm
OK, this is a weird one, and not terribly important although it did
make me go "huh?" for a couple of days. I'm curious as to whether
this is a bug and what causes it. It surely can't be intentional?
I'm using mutt-1.5.14-4 as seen on Fedora 7, compiled with ncurses 5.6,
in an xterm (X.Org 6.8.9
On Mon, May 21, 2007 at 10:23:01PM +0200, Elimar Riesebieter wrote:
> On Debian we can't build ncurses with --enable-ext-mouse, because
> binutils's ld doesn't know -lstdc++ :
>
> /usr/bin/ld: cannot find -lstdc++
I think on Linux you're supposed to invoke ld via gcc rather than
directly (at leas
On Fri, Mar 23, 2007 at 02:52:24AM +, Dave wrote:
> Check this out:
> $ cat --version
> cat (coreutils) 5.2.1
> Written by Torbjorn Granlund and Richard M. Stallman.
>
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is
On Sat, Mar 17, 2007 at 09:54:25AM -0400, Derek Martin wrote:
> On Sat, Mar 17, 2007 at 11:08:12AM +0000, Ian Collier wrote:
> > In that case, you get them to download an authorized_keys file for ssh...
> Well sure, there's only so much Mutt can do on its own -- and
> rem
On Fri, Mar 16, 2007 at 10:22:05PM -0400, Derek Martin wrote:
> On Fri, Mar 16, 2007 at 12:40:27AM +, Paul Walker wrote:
> > If you can modify someones personal files, the game's already over.
> Not so. At least not necessarily.
So!
> Say there's a (purely hypothetical) bug in Mutt which al
34 matches
Mail list logo
