Re: [OT] Terminal redraw issues / isync launchctl job in macOS 13.5
On Mon, Aug 07, 2023, Jan Eden via Mutt-users wrote: > I recently upgraded to macOS 13.5, and for the first time, there are > redraw issues in the Terminal with mutt (2.2.10, installed via "Terminal" broke screen handling for me in MacOS 13.5 with various programs - even vi. Maybe file a bug with Apple? Others suggested I should switch to iTerm2 which doesn't seem to have the problem.
Re: Scheduling deferred sending of emails
Just some idea (untested): 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. For sendmail: - use -odq - the script needs to parse the output 250 2.0.0 $QID Message accepted for delivery and get the "queue id" $QID. - use at to schedule sendmail -qI$QId - either do not run the queue at all or put your submitted mails in a "queue group" which is not processed by default. For details: see man sendmail and doc/op/op.* Other idea: use quarantining (also see doc/op/op.* from sendmail for details).
Re: top and bottom margin
On Wed, Mar 29, 2023, Mark E. Mallett wrote: > to add and implement a couple of muttrc variables to set a top and > bottom margin, since I like to break up any wall of solid text. As I "Back then" I had my own patches to do that. > This actually used to be a fairly non-trivial patch, having to calculate > offsets here and there, but at some point mutt 'window' management was > changed and the margins got a lot easier. Of course I don't know that For me it was the opposite: the original patch was simple, but with that change it broke and I never got it to work properly again (it "works" ok until something changes the layout and then the empty lines are gone so I exit mutt and start it again). Is your patch available somewhere? Maybe it works better for me than the hack I have.
Re: ssl_starttls unknown variable
Maybe a basic check first: mutt -v | fgrep '+USE_SSL_GNUTLS' Does it show what you configured?
Re: A bit off-topic: problems with sending to a Gmail user
On Fri, Mar 11, 2022, Stefan Hagen wrote: > > > 550-5.7.26 This message does not have authentication information or > > > fails to > Authenticated in this context means, you don't have SPF / DKIM / DMARC set up. [more off-topic/rant] Isn't it nice how Google et.al. enforce things which are neither mandatory nor really useful to "fight spam"? All the spam I get at $WORK is from gmail and it has passed all of those "requirements" -- but the "investment"/"loan"/... spam/scams are not filtered at all by Google themselves (hey, why should they do outbound spam filtering? it cost them money and why should they care? it's not like anyone important would block gmail -- but Google rejects mail coming to them due to bogus reasons). "Solution": ask gmail users to switch to other services which do not have so many "false positives". PS: maybe there is an option in gmail for users to whitelist senders from whom they want to receive mail?
Re: Slightly OT: I'm looking for a tool to merge maildirs
I recently wrote something like that but for mailboxes. It uses formail etc and requires that each mail has a Message-Id (which some didn't have...). Look into the -D and -s options of formail, maybe it works for maildirs too?
Re: Why uw.edu not accepted my signed email?
As I wrote before: check some online articles (this is not a problem with mutt). In this case it seems the problem might be on the server side. You can probably disable the use of DH ciphers (in sendmail) in general or at least with those servers (that might require a newer sendmail version).
Re: Why uw.edu not accepted my signed email?
On Wed, Nov 17, 2021, Andrew D. Arenson wrote: > Oct 21 19:52:35 redsolar sm-mta[1465905]: STARTTLS=client, error: > connect failed=-1, reason=dh key too small, SSL_error=1, errno=0, It seems your sendmail version is a bit old? Check your favorite search engine... you need to generate a larger DH key - how to do that depends on your OS (or maybe update sendmail or disable DH?)
Re: Why uw.edu not accepted my signed email?
On Tue, Nov 16, 2021, Andrew D. Arenson wrote: > I don't see any obvious configurations that set how email is > sent, so my guess is that it is being send via sendmail on my > Ubuntu workstation. Then you should be able to check the maillog(?) for those TLS problems and also check the mail queue: mailq Also check the DSN again: does it say which is the "reporting MTA"? That's most likely the one which has the TLS problem with uw.edu.
Re: Why uw.edu not accepted my signed email?
On Tue, Nov 16, 2021, Andrew D. Arenson wrote: > Deferred: 403 4.7.0 TLS handshake failed. This has nothing to do with the content of the mail, it's a problem between the program you use to send (submit?) the mail at the SMTP level and the MTA at uw.edu. Do you use mutt directly for this or some MTA? Check whatever (START)TLS configuration you use for that. -- Please don't Cc: me, use only the list for replies.
Re: not to set message id in outgoing email
On Wed, Feb 03, 2021, Will Yardley wrote: > Even if Mutt doesn't set one, the first MTA it hits will add one. Not Not really - a MTA should not make such changes. A MSA should do it, but Message-Id: is a SHOULD not a MUST. > What exactly is your goal here? That's the important question, aka "What's the problem you are trying to solve?"
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Jan 31, 2021, Chinmaya Nagpal wrote: > I have a similar setup as yours, except I use the built-in SMTP. What > advantages are there to using an external sendmail program? Queueing.
Re: more general hooks to handle similar mailing lists
On Sun, Oct 11, 2020, Remco Rnders wrote: > > save-hook "~C ietf-\\([a-z0-9]+\\)@ietf.org" =%1 > I know it is not a direct answer to your question, but it might perhaps get > the > end result you want; Have you considered using procmail or a sieve filter to > automatically save mail matching your regex to the folder you want? I'm doing that, but the theoretical configuration command above was just one example of what I would like to do -- something like "parameterized" commands. Other examples would be send-hook ietf-\([a-z0-9]+\\)@ietf.org 'my_hdr From: My Name ' folder-hook ietf-\([a-z0-9]+\\) 'my_hdr From: My Name '
more general hooks to handle similar mailing lists
I'm trying to use a more generic approach for some patterns to handle mailing list, e.g., something like: save-hook "~C ietf-\\([a-z0-9]+\\)@ietf.org" =%1 instead of having one entry for each mailing list. Is that possible with the current mutt features? It seems that back-references in regular expressions can only be used for "spam": spam pattern format ... format can be any static text, but it also can include back-references from the pattern expression. If that's the case, would it be useful to extend it to other (all) uses?
Re: any new progress on OAuth 2 / Office365 access
On Fri, Jun 05, 2020, Will Yardley wrote: > Anyone have any tricks / tips for accessing Office365 via Mutt? I know Someone at $WORK got frustrated enough that he used Davmail to access his mail. However, it seems it is specific to the fubared $WORK setup? Here's a part of what he wrote about Davmail: 1) MAPI to IMAP gateway, since the IMAP connector on our O365 instance has been disabled. Even if we had OA2+SSO working we still have no IMAP. 2) Handles the OA2+SSO token communication. Sorry, I don't have any further information since I convinced IT at $WORK that I need local IMAP access (which can only be reached if you are connected via the VPN).
Re: ggp related changes (1.9 - 1.12)?
On Fri, Dec 27, 2019, Kevin J. McCarthy wrote: > Try refreshing your pgp_* commands against the version in contrib/gpg.rc in Thanks, that solved the problem. Seems I didn't look far enough back in the ChangeLog, sorry. Now I need to find some time to resolve the merge conflicts so that my changes will still work in newer mutt versions.
ggp related changes (1.9 - 1.12)?
So I'm a "bit behind" and recently updated to 1.12.1 (from 1.9.x) Based on ChangeLog I added unset pgp_use_gpg_agent to my muttrc which at least gives me a prompt asking for the pass phrase (I'm not sure why that is set by default if there is no gpgv2 on the system?). However, I can no longer decrypt mails (using gpg 1.4.23) "Could not decrypt ..." What other things do I need to change to make this work again? I didn't see anything else that is relevant in ChangeLog, what am I missing? [I tried to update to 1.13.2 but there are too many merge conflicts which will take some time to resolve :-(] -- PS: please reply to the mailing list, thanks.
Re: envelope sender address setting
On Mon, Sep 23, 2019, rand pie wrote: > How to set the sendmail binary sender address > base on different email addresses with mutt? *-hook might work, e.g., something like: folder-hook . "set sendmail=\"/usr/sbin/sendmail -i -oem -fUSER@B.C\"" send-hook ietf-smtp "set sendmail=\"/usr/sbin/sendmail -i -oem -fietf-smtp@B.C\""
Re: Hide a message?
On Wed, Dec 12, 2018, Victor Sudakov wrote: > Is there a way to hide a message (e.g. with a certain subject) from view in > a mailbox, without actually deleting it? Maybe this works: show only messages matching a pattern Details can be found in the documentation.
Re: Test number two - spaces
On Sat, Oct 27, 2018, Ian Zimmerman wrote: > On 2018-10-27 18:23, Claus Assmann wrote: > > Just FYI: both test mails passed verification for me. > RGH!! I am losing my mind!! Hopefully it's backed up somewhere... > Here are the intermediate Received headers of the 2nd test mail as it > came back to me. Can you share the ones in your copy? I deleted the mails already :-( However, below are the Received headers of your most recent mail. If you kept a copies of the mails which you originally sent and which you got back: what's the "diff"? Moreover, I downloaded the "raw" message from the MARC archive, added some headers, and it verifies too. So I'm attaching that as .gz file so it doesn't get messed up by some mail software. Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id A9B91227F9; Sun, 28 Oct 2018 03:42:34 + (UTC) Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3tMY4OIzjA6; Sun, 28 Oct 2018 03:42:33 + (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by silver.osuosl.org (Postfix) with ESMTP id 4C728227C1; Sun, 28 Oct 2018 03:42:33 + (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id C57471BF61D for ; Sun, 28 Oct 2018 03:42:32 + (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id C2B3B86767 for ; Sun, 28 Oct 2018 03:42:32 + (UTC) Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o-8499bbnC7 for ; Sun, 28 Oct 2018 03:42:32 + (UTC) Received: from very.loosely.org (very.loosely.org [173.255.215.69]) by whitealder.osuosl.org (Postfix) with ESMTPS id 2D87886761 for ; Sun, 28 Oct 2018 03:42:32 + (UTC) Received: from itz by ahiker.mooo.com with local (Exim 4.91_26-9591063a) (envelope-from ) id 1gGbtd-PD-8F for mutt-users@mutt.org; Sat, 27 Oct 2018 20:37:49 -0700 m2.gz Description: application/gunzip
Re: Test number two - spaces
On Sun, Oct 28, 2018, Ken Moffat wrote: > 3. Neither the post you were asking about, nor either of your tests, > passed verification here. Just FYI: both test mails passed verification for me.
Re: muttrc for different mutt versions
On Thu, Sep 06, 2018, Kai Weber wrote: > How can I have the same muttrc on both machines without running into > errors during mutt start? I split the rc file into 1) a common part 2) parts specific to the mutt version and - source the common part (1) in the specific version (2) - use a wrapper which invokes mutt with the specific rc file (2)
"fast" save of attachments from multiple messages
Is there some fast way to save the attachments from multiple messages? That is, without going to every individual message, viewing and then saving the attachments? I can tag the attachments in a single message and save them easily, but seemingly not for multiple messages (AFAICT). Something like a "save attachments" option (after tagging the messages) or some "clever" macro? This would be useful as I sometimes get many messages with one attachment each instead of one message with many attachments (e.g., to avoid messages that are too large for some MTA configurations).
Re: Quote multiple messages in new message
On Wed, Jan 17, 2018, steve wrote: > I tried to tag some messages > with T then type ;m but this create an empty new message. Did you try "reply"? ;r
Re: layout hack: blank 2nd line
Thanks for the patch, your approach is so much simpler than what I tried so far. In some basic testing it does what I want -- I also added a blank line near the bottom (and now I have to figure out that hg stuff to maintain a branch(?)/clone(?) of the original code plus some local changes).
layout hack: blank 2nd line
I hacked an old mutt version to have a blank line between the status (on top) and the list of mails, e.g., it looks like this: Mbox: =admin (-) [[rest of status line]] 214 2016 Mar 01 Charlie Root( 33) esmtp.org daily insecurity output 215 2016 Mar 01 Cron Daemon ( 21) Cron mailq How to get that blank line between the status and the rest in new mutt versions? My hack doesn't apply anymore when the code was changed for the sidebar stuff :-( Is there an option/trick or does it require a source code change? In the latter case: does someone have a patch? I tried but so far failed to hack the new code :-(
Re: [OT?] please do not tag messages as spam
Sorry about that, it's actually something at the mailing list server that does this : it not only adds X-FidoGuard-... headers, but also munges the Subject with some utf-8 token (which seems like a useless "encoding"). That software obviously has too many false-positives :-(
[SPAM?] [OT?] please do not tag messages as spam
IMNSHO it's rather annoying when people send mail to the list and add a [SPAM] tag to the Subject: header. If it were spam, why would you send it to the list? [maybe the mailing list SW could filter/reject such mails :-) ...] -- Reply-To: is set, please do not Cc' me.
Re: New thread about PGP sigs, part 1: Mutt disagrees with gpg
On Thu, Sep 22, 2016, Ian Zimmerman wrote: > muttgpg > http://marc.info/?l=mutt-users=147417425713497=rawBAD GOOD Verifies fine for me (in mutt). Now the question is: is it "just" your setup, or does it fail for others too? If so, what is common between the setups where the verification fails?
Re: saved or deleted?
On Tue, Aug 30, 2016, Derek Martin wrote:
> Why, then, do you feel the need to distinguish between a deletion
> caused by a copy, and a deletion caused by you explicitly deleting the
> message? In both cases, it is legitimately a deletion.
In the former case the user still has a copy of the message, in the
latter case most likely not...
Seems like a good addition IMHO ("did I actually copied it to
a different folder or did I simply delete it?")
Re: BAD signature: mutt, signer, something else?
On Mon, Jun 27, 2016, Will Yardley wrote: > On Mon, Jun 27, 2016 at 10:48:54AM -0700, Claus Assmann wrote: > > mutt/gpg gives me a "BAD signature" for some recent mails on the > > openssl users list, one example message is attached. Can someone > > else reproduce the problem (the author says it verifies for him)? > Does it verify when he receives a copy from the list? Yes (according to his reply to my question). > I saved the signature and text part of the email separately, and also > get bad signature with gpg2 via commandline (and no extra info that > might explain it). I tried that too but can't get it to verify even after following RFC 3156: MIME Security with OpenPGP which requires as line endings, no trailing white space, inclusion of content headers, etc, but then I can't even verify the example in the RFC following those instructions :-( However, if I use mutt to sign and send a message to myself, I can verify it - via mutt and - "by hand" based on the RFC.
BAD signature: mutt, signer, something else?
mutt/gpg gives me a "BAD signature" for some recent mails on the openssl users list, one example message is attached. Can someone else reproduce the problem (the author says it verifies for him)? If the signature verifies for you, which mutt / gpg version do you use? (and any hints what might be broken in my setup?) Mutt 1.5.24+24 (4de4b3635140) (2015-08-30) gpg (GnuPG) 1.4.19 mc1.gz Description: application/gunzip
Re: Send mail in background with built-in SMTP client?
On Thu, Apr 14, 2016, Xu Wang wrote: > I use mutt's built-in SMTP client. I would like to press 'y' and > immediately be able to move on to my next email without waiting. I Did you check the fine manual? 3.234. sendmail_wait Type: number Default: 0 Specifies the number of seconds to wait for the $sendmail process to finish before giving up and putting delivery in the background. Mutt interprets the value of this variable as follows: +-+ |>0|number of seconds to wait for sendmail to finish before continuing| |--+--| |0 |wait forever for sendmail to finish | |--+--| |<0|always put sendmail in the background without waiting | +-+ Note that if you specify a value other than 0, the output of the child process will be put in a temporary file. If there is some error, you will be informed as to where to find the output.
Re: Need passphrase for unencrypting but not for signing
On Tue, Jan 26, 2016, Xu Wang wrote: > that in order to decrypt a message I need to put my passphrase in. But > for signing, I do not need to. Is this normal? It is the same Are you replying to an encrypted mail? Then the pass phrase is most likely still cached. See the fine manual, look for pgp_timeout or something like that.
1.3.28: still not possible to compile without iconv
I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? I've attached a patch that seems to work. It's a bit of hack, a clean solution would be to have an iconv.h substitute that defines the prototypes of the replacement functions which are in charset.c and also defines iconv_t and EILSEQ. This would localize the changes instead of spreading them out over many files. diff -c -r mutt-1.3.28/charset.c mutt-1.3.28-/charset.c *** mutt-1.3.28/charset.c Tue Jan 22 17:02:39 2002 --- mutt-1.3.28-/charset.c Sun Mar 17 15:53:57 2002 *** *** 31,37 --- 31,39 #include unistd.h #include errno.h + #ifdef HAVE_ICONV #include iconv.h + #endif #include mutt.h #include charset.h diff -c -r mutt-1.3.28/charset.h mutt-1.3.28-/charset.h *** mutt-1.3.28/charset.h Tue Feb 13 14:06:14 2001 --- mutt-1.3.28-/charset.h Sun Mar 17 15:46:58 2002 *** *** 19,25 --- 19,29 #ifndef _CHARSET_H #define _CHARSET_H + #if HAVE_ICONV #include iconv.h + #else + #define iconv_t int + #endif int mutt_convert_string (char **, const char *, const char *, int); diff -c -r mutt-1.3.28/gnupgparse.c mutt-1.3.28-/gnupgparse.c *** mutt-1.3.28/gnupgparse.cWed Aug 1 07:06:58 2001 --- mutt-1.3.28-/gnupgparse.c Sun Mar 17 15:54:48 2002 *** *** 44,50 --- 44,52 #include mutt.h #include pgp.h #include charset.h + #ifdef HAVE_ICONV #include iconv.h + #endif /* for hexval */ #include mime.h diff -c -r mutt-1.3.28/rfc2047.c mutt-1.3.28-/rfc2047.c *** mutt-1.3.28/rfc2047.c Mon Oct 15 13:18:32 2001 --- mutt-1.3.28-/rfc2047.c Sun Mar 17 15:50:10 2002 *** *** 24,30 --- 24,32 #include ctype.h #include errno.h + #if HAVE_ICONV #include iconv.h + #endif #include stdio.h #include stdlib.h #include string.h diff -c -r mutt-1.3.28/sendlib.c mutt-1.3.28-/sendlib.c *** mutt-1.3.28/sendlib.c Wed Nov 7 02:51:29 2001 --- mutt-1.3.28-/sendlib.c Sun Mar 17 15:53:39 2002 *** *** 649,654 --- 649,657 } /* Define as 1 if iconv sometimes returns -1(EILSEQ) instead of transcribing. */ + #ifndef EILSEQ + # define EILSEQ EINVAL + #endif #define BUGGY_ICONV 1 /*
Re: 1.3.28: still not possible to compile without iconv
On Sun, Mar 17, 2002, David Champion wrote: * On 2002.03.17, in [EMAIL PROTECTED], * Claus Assmann wrote: I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? Lars Hecking posted a patch to mutt-dev over a month ago. It's still awaiting testers before it can be merged into the tree for 1.4. It seems to work for him, but very few truly iconv-less people have tried it and reported back. See http://groups.yahoo.com/group/mutt-dev/message/13851 Thanks, I found the message in a different archive (groups.yahoo.com wants cookies...) Feedback: it compiles fine on my machine (OpenBSD 2.8) and it seems to work (only basic testing). So please merge it before 1.4. Thanks! (sorry, I don't read mutt-dev anymore, I'm getting more than 500 mails a day (obviously I can only skim through the subjects and read only a subset...))
--without-iconv doesn't work?
System: OpenBSD 2.8
./configure --without-iconv
doesn't work:
checking for catalogs to be installed... de ru it es uk fr pl nl cs id sk ko el zh_TW
zh_CN pt_BR eo gl sv da lt tr ja hu et ca
configure: error: Unable to find an iconv function. See INSTALL for help
I read the INSTALL file, that's why I used
--without-iconv
BTW:
http://clisp.cons.org/~haible/packages-libiconv.html
gives 404.
Before you yell at me: I found the package (later on there is
an ftp URL).
So which part of the INSTALL file is correct: must I install
yet another library or is there a way to turn iconv off?
According to these lines in configure:
if test $am_cv_func_iconv != yes
then
{ echo configure: error: Unable to find an iconv function. See INSTALL for help
12; exit 1; }
fi
it's not possible to be turned off...
Re: --without-iconv doesn't work?
On Wed, Jan 02, 2002, Daniel Eisenbud wrote: This is annoying. I've successfully compiled mutt without iconv by commenting out lines in config.h, so I think that this is just a braindead policy decision. Try commenting out the iconv test you quoted below in configure, and see what happens when you configure and build without iconv. Also note that for some reason the iconv macro is It fails in compilation (this is mutt-1.3.25). I started hacking to get around the missing iconv stuff, but there seems to be too much depending on it, e.g., charset.h includes iconv.h, if I change that to: #if HAVE_ICONV #include iconv.h #endif then it fails somewhere else: Making all in contrib gcc ... -DHAVE_CONFIG_H=1 -I. -I. -Iintl -I./intl -Wall -pedantic -g -O2 -c patchlist.c In file included from mutt.h:51, from patchlist.c:5: charset.h:28: syntax error before `mutt_iconv_open' charset.h:28: warning: type defaults to `int' in declaration of `mutt_iconv_open' charset.h:28: ANSI C forbids data definition with no type or storage class charset.h:29: syntax error before `const' In file included from mutt.h:812, from patchlist.c:5: protos.h:162: syntax error before `iconv_t' *** Error code 1 Does your system have the iconv.h file etc? Or did you change more than just config.h?
message output after mutt terminates?
This behaviour is a bit strange on my OpenBSD 2.8 system: $ ./mutt -f =mutt 123 kept, 3 deleted. Between those two lines I read some mail and deleted 3. At the end mutt asked me whether to (really) delete them. I typed 'y' and then I had to hit return, which is different from the old behaviour (I was running 1.0i before). Thereafter the line 123 kept, 3 deleted. was printed. Mutt 1.3.25i (2002-01-01) Copyright (C) 1996-2001 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: OpenBSD 2.8 (i386) [using ncurses 5.2] Compile options: -DOMAIN +DEBUG -HOMESPOOL -USE_SETGID +USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK -USE_POP -USE_IMAP -USE_GSS -USE_SSL -USE_SASL +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK -HAVE_WC_FUNCS -HAVE_LANGINFO_CODESET ++HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID -HAVE_GETADDRINFO -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/home/ca/share/mutt SYSCONFDIR=/home/ca/etc EXECSHELL=/bin/sh -MIXMASTER To contact the developers, please mail to [EMAIL PROTECTED]. To report a bug, please use the flea(1) utility.
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Wed, May 16, 2001, Louis-David Mitterrand wrote: You're going to add an MTA first (reimplement sendmail). Then Huh? Adding a few dozen lines of code to deliver via SMTP is reimplementing sendmail? You need a serious reality check. a few dozen lines of code... Did you ever write a SMTP client? Oh yeah, let's start simple: no queueing, just EHLO (oops, can't use that always, so maybe HELO), MAIL, RCPT, DATA, QUIT. What about temporary errors? Do you tell the user: sorry, please try again later? Or do you implement queueing? Who runs the queue? When? What about SMTP AUTH, STARTTLS, DSN, DELIVER-BY, ... ? Sorry, but Unix is built out of tools. Use them (or use Emacs, which has everything built in). Or the other answer: you got the source, you can add the functionality as you like. Publish it and see what happens.
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Wed, May 16, 2001, Louis-David Mitterrand wrote: Yes, telling the user try later or postpone your message and fix your config is better than injecting the message into a poorly configured /usr/sbin/sendail that will drop it on the floor without reporting it. What a great alternative... how about not breaking the MTA in the first place? Sorry, but Unix is built out of tools. Use them (or use Emacs, which has everything built in). You mean mutt should be like emacs and have everything built-in? That's what you seem to want, not me. Please read my sentence again. If you want everything in one program: use emacs. Either we agree or you contradict yourself. Neither nor. On Wed, May 16, 2001, Louis-David Mitterrand wrote: Certainly not. Who needs a queue? Either the mail is delivered or the user will be presented with a failure and invited to postpone his message and fix his config or ask the admin what's wrong with the relay MTA. Very useful (NOT). I had the fun of having to deal with an MTA that didn't queue message in case of temporary failures. It's just plain stupid. This discussion is useless. See my first answer: you can do whatever you want. Use the source, you got it (and even a patch).
Re: sendmail error
On Thu, Nov 30, 2000, Kelly Scroggins wrote: The error produced by Mutt is : /etc/sendmail.cf: line 90: fileclass: cannot open /etc/sendmail.cw: Group writable directory It's not mutt, it's sendmail. -rw-r--r-- 1 root root 59 Sep 1 1999 /etc/sendmail.cw It's complaining about the directory, not the file. See the sendmail README file. chmod go-w / /etc
Re: mutt/sendmail mailing list problem
On Wed, Oct 04, 2000, Peter Jaques wrote: it does; i used to get all the "x-authentication-warning"s, till i changed my sendmail.cf. sendmail IS honoring the -f; it correctly sets the "From " header. it just doesn't set "Return-path" right. This is somewhat off-topic for mutt... The Return-Path: header is set by the receiving MTA (based on the envelope sender). You can't set the former (but the latter). If your e-mail address is rewritten (masquerading, genericstable, CNAME, ...), then the receiving system may use a different address then the one you specified with -f.
Re: sending mail
On Wed, Sep 27, 2000, Mikko Hänninen wrote: Suresh Ramasubramanian [EMAIL PROTECTED] wrote on Wed, 27 Sep 2000: Well... Thanks for this quick answer, but what choice do I have ? Making my machine to resolve in the outside world, or have mails bounce, or having this authentication warning ? I think there is one more choice left out the list here: replace the MTA (sendmail). Or perhaps you can also reconfigure it. My personal You can just reconfigure it, it's trivial. Remove authwarnings from PrivacyOptions, that's it. There are other ways to get rid of the message, but this isn't a sendmail list.
Re: Bug in mutt's detection of recipients on command line
On Thu, Sep 21, 2000, Charles Cazabon wrote: I seem to have found a bug in mutt, when using 'mutt recipient_address' from the commandline. Minimal test case follows: [charon]$ mutt foo@[EMAIL PROTECTED] That's not a valid address. It works fine with zero or one '@' signs in an address; anything more causes it to quit. This is causing problems for some scripts I've got which use mutt to send mail because of its attachment-handling capabilities. Any easy workaround? Use valid addresses?
Re: Mutt and TLS
On Mon, Apr 17, 2000, Ralf Hildebrandt wrote: Does mutt support TLS as described in http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/ ? Why should it? mutt doesn't use SMTP...
Re: Mutt S/MIME
On Thu, Feb 10, 2000, Thomas Roessler wrote: On 2000-02-09 18:15:03 -0500, Adam Sherman wrote: Would it be possible to use Mutt with S/MIME cryptography? It wouldn't be difficult to add support for this to mutt, once you have a command-line based tool with the cryptographic functionality. openssl has this for some time now, but it's just in the snapshots, not yet released. I tried to verify some signatures and it works fine.
Re: Changing X-Sender header
On Wed, Feb 09, 2000, Lars Hecking wrote: The Sender: header is written by the MTA (eg. sendmail). sendmail does not generate a "Sender:" header. Which MTA does it?
Re: Vacation problem
On Wed, Nov 10, 1999, Shane Castle wrote: It serves absolutely no useful purpose and causes more problems that anything it was intended to solve. PLEASE don't use it! Don't even try to fix it; it's too broken! Which version are you talking about? IMHO it is a very useful program, there are just too many broken versions around. That's why sendmail 8.10 comes with a vacation program.
quoted-printable in header
Hi! I've received an e-mail where the From: header line contains a quoted-printable encoded name: From: =?iso-8859-1?Q?=22F=FCr=2C_Per=22?= [name changed, address omitted...] As you can see, this translates to: "Für, Per" However, the quotes have been encoded too. Replying to this causes mutt (0.95.6i) to change the header into: "\"Für, Per\"" i.e., putting quotes around the whole name part. Question: is the encoding in the original From: header line broken? Is mutt's treatment of the header line broken? It works fine if the quotes are not encoded, e.g., From: "=?iso-8859-1?Q?F=FCr=2C_Per?=" TIA.
Re: DSN feature in sendmail 8.9
On Sat, Jul 10, 1999, Aris Mulyono wrote: I tried to set dsn_notify and dsn_return variable in mutt but when I sent the email the sendmail complained about the option -N not being recognized. What FEATURE should I enable specifically in sendmail to do this? None. It is enabled by default. Do you really use sendmail 8.9? Maybe you should ask in a sendmail group...
RFE: ask for PGP passphrase: which key?
Is there a chance to modify the prompt:
Enter PGP passphrase:
to include an identification of the key that is required?
Background: I have multiple PGP keys protected with different
passphrases. Sometimes it is not clear which PGP key has been used
for encryption and then I have to look at the message to see for
whom it is. If mutt could try to lookup possible recipients in
alternates and tell me for which of those the mail is, then I could
enter the correct passphrase immediately. (In case you wonder:
some PGP keys are shared with others ("role accounts") and I prefer
to have different passphrases for them).
I know this doesn't work all the time, but it seems to be a
useful enhancement.
Any comments?
Re: Return Address problem
On Fri, Apr 23, 1999, Hal Burgiss wrote: Maybe this discussion should be done in a sendmail related list/group? Well I am starting sendmail as : sendmail -bd -f [EMAIL PROTECTED] I thought this might help, but doesn't seem to. The daemon ignores the -f option for obvious reasons: you don't want all mail going through it to be from that address...
Re: disable X-Mailer:?
On Tue, Feb 16, 1999, Randall Hopper wrote: Claus Assmann: |Question: how can I disable the X-Mailer: header? I wonder if this would work: unmy_hdr X-Mailer Haven't tried it, but it seems like it should. Unless I did something wrong, it doesn't work. I use the suggestion CFLAGS="-DNO_XMAILER" which seems to be the simplest way. Thanks to all who responded!
disable X-Mailer:? (was: [Announce] Mutt 0.95.3 is out.)
On Fri, Feb 12, 1999, Thomas Roessler wrote: Mutt 0.95.3 is out. This version should be considered BETA. Question: how can I disable the X-Mailer: header? Before this version I used to patch config.h, but now the definition is in acconfig.h, which seems to be nowhere included... Is there some easy/recommended way to do this? (currently I've added the define to config.h again).
