Re: Q Forawrd without previous headers?
Jonathan Gift proclaimed on mutt-users that: I find that when I'm forwarding an email, it forwards all the previous headers. There must be a setting in .muttrc to turn it off. I tried unset forward_quote but no go. set forward_decode=ask-no # weed and MIME decode forwaded messages this should also help ... set mime_forward=ask-no # use message/rfc822 type to forward -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.
Forward/Bounce without Delivered-To: headers
Since Postfix uses Delivered-To: for improved loop-detection, I need to strip this and only this header upon bouncing a message using "b". How? I use mutt-1.2.5 an 1.3.8 -- [EMAIL PROTECTED] System Engineerinnominate AG Diplom-Informatiker the linux architects tel: +49.30.308806-62 fax: -698 www.innominate.com PGP signature
Re: Summary: courier-mta BROKEN.
Anand Buddhdev writes: * Unspecified content-type charset. Courier will provide one. * Unspecified transfer encoding. Courier will calculate the best encoding and use that. Ok. I've attached the message here. It has a Content-Type charset specified. It also specifies a Content-Transfer-Encoding header. Both were inserted by mutt. What courier did was not to change the headers, but to re-order them, and that caused the signature to become invalid. So, the question is, why did courier change the order of the headers when they were perfectly valid? Can't say. The headers in the attached message were rewritten :-) Let's try this as inlined text/plain, or attach it as application/octet-stream. -- Sam
Re: message to Peter Pentchev
On Mon, Dec 04, 2000 at 08:34:41PM +0100, William Maddler wrote: looks like in ur test u left [EMAIL PROTECTED] as ur mail address... ;))) I have a couple mails here for u... lemme know ur addie... ;)) Heh actually it's in the previous message's headers - [EMAIL PROTECTED] :) And I actually received the messages - they were CC:d to a mailing list or two. Sorry about that! :) G'luck, Peter -- This sentence no verb.
courier-mta, mutt and PGP
On Tue, Dec 05, 2000 at 08:31:43AM -0500, Sam Varshavchik wrote: Hi Sam, Thank you very much for this detailed answer. I now understand what the problem is. I just concluded a test, where I manually inserted a Content-Transfer-Encoding: header into the main headers of the mail, and used only 7bit content throughout. Indeed, courier did not touch the message, and it came through just fine, and also verified correctly. So the problem boils down to the MUA not generating full and correct MIME headers. In this case, mutt isn't inserting all the headers that courier expects (it assumes that the relevant information will be infered according to RFC 1847). I suppose mutt's interpretation of the RFC is understandable. Anyway, the result is that a user has to go to extra effort to make sure that PGP/MIME messages are correctly encoded, to avoid changes along the way. I just don't want to go to such extra effort every time. It's hard to remember and make sure the headers are correct everytime - that's the job of the MUA. Do you have any suggestions for alternative mail clients that have better MIME support? Alternatively, do the mutt users have any ideas on making mutt generate the headers as Sam suggests? Here are just the MIME headers from your test message: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline Here's the first MIME section: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here's the second MIME section: Content-Type: application/pgp-signature Content-Disposition: inline Note that the second MIME section does not specify its content transfer encoding. Neither is the default transfer encoding specified in the top level MIME header. As I mentioned, if a MIME section that does explicitly specify its transfer encoding, Courier will calculate one. I believe that if you had a "Content-Transfer-Encoding: 7bit" *either* in the top level MIME headers, which will set a default for the whole message, or in the application/pgp-signature MIME section, Courier will not rewrite it. If you notice, when Courier rewrites the message, it regenerates all the MIME headers. The top level MIME headers will set a default "Content-Transfer-Encoding: 7bit", header. Because that's also the encoding for the second MIME section, it doesn't have to specify it explicitly. Basically, the message is rewritten and the MIME headers are regenerated. It just so happens that when the headers are regenerated, the order of the headers in the second MIME section is reversed. But, having "Content-Transfer-Encoding: 7bit" specified either in the top level MIME header, or in the application/pgp-signature MIME section would avoid the need to provide a default encoding. -- Anand
Screen gabage (newbie)
Hi. I just started using mutt, and have a question. After many screen changes (going to the next message, etc), my screen doesn't update completly (some garbage from the previous mail remains). Ctrl+L helps. Any ideas how this can be solved? (I looked at the FAQ and list archive but can't find the anwer). I'm using mutt 1.2.5i on IRIX 6.5 [using ncurses 5.2], using SGI xwsh. Thanks. -- Micha
Re: Forward/Bounce without Delivered-To: headers
On Tue, Dec 05, 2000 at 10:23:24AM +0100, Ralf Hildebrandt wrote: Since Postfix uses Delivered-To: for improved loop-detection, I need to strip this and only this header upon bouncing a message using "b". How? unset bounce_delivered -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | RF Communications Product Generation Unit | Spokane, Washington, USA
Re: Wrong Lines count in the header after attachment deleted
On Mon, Dec 04, 2000 at 13:57:44 -0600, Petr Hlustik wrote: Hi, A trivial problem using 1.2i: after I delete an attachment, sometimes the index keeps showing huge message size, possibly because the Lines: field in the header has not been modified. If I try showing headers and edit-message, this field is off limits. Any ideas how to fix this? Deletion of attachments marked for deletion will first take place when you close or sync (by typing $ with default key bindings) the current mailbox. But then the line count should automatically be updated; it is a bug if it is not. In that case I would like to see one of the messages with wrong line count (it would be perfect if you can also provide a copy of the message taken before the attachment deletion). I also would like to know what kind of mailbox format (mbox, MH, Maildir or other) you use. -- Byrial http://home.worldonline.dk/~byrial/
Mutt and HTML body
Hello, im quite a new user for Mutt. I would like to send a mail with a html body, how could i do that. I have tried a header with Content-Type : text/html but it doesn't work. best regards jacques Giudicelli
Re: Mutt and HTML body
On Tue, Dec 05, 2000 at 06:19:14PM +0100, Jacques Giudicelli wrote: Hello, im quite a new user for Mutt. I would like to send a mail with a html body, how could i do that. I have tried a header with Content-Type : text/html but it doesn't work. is this a joke? :) but seriously, no, I don't think there is a way to do this. Change the content type to text/html (control-T in the compose menu), and just put html in the body of the email. but -- never send it to me! ttyl, -- Josh Huber | [EMAIL PROTECTED] | 1024D/6B21489A 61F0 6138 BE7B FEBF A223 E9D1 BFE1 2065 6B21 489A PGP signature
Re: Mutt and HTML body
On Tuesday, December 05, 2000 (CS:2.49.340) 12:57:45 [PM] (-0500) Josh Huber [[EMAIL PROTECTED]] wrote... is this a joke? :) This has to be a joke - a very bad one... but -- never send it to me! to me neigher... mh -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Linux Forever! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PGP signature
Re: Mutt and HTML body
This thread reminds me: where can I find the Mutt Assistant? I can't find the setting right now, but I'm sure there's a way to turn it on. It's supposed to be like an animated paper clip, giving me good advice while I'm composing an e-mail. I'm sure I've seen it somewhere. It's very useful. Can you help me? Jesper p.s. this _is_ a joke, BTW. -- "But how can one be warm alone?" Jesper Holmberg [EMAIL PROTECTED]
Re: Mutt and HTML body
On Tue, Dec 05, 2000 at 06:19:14PM +0100, Jacques Giudicelli wrote: Hello, Heys! im quite a new user for Mutt. I would like to send a mail with a html body, how could i do that. I have tried a header with Content-Type : text/html but it doesn't work. Don't forget to type HTML. Oh and ... it's generally considered inappropriate to use a markup language to send mail to people. Use text/plain instead. -- GUI What your computer becomes after spilling your coffee on it. (pronounced 'gooey')
Re: Recording Bcc fields in fcc copy
Julian Gilbey muttered: [Please cc replies to me!] I want to save any Bcc headers I have used in copies of mail I save to file using the Fcc: feature. Mutt seems to strip them before it saves the mail to file, which is really annoying. Is there any way I can do this? (Haven't found any mention of this behaviour in the docs.) I'm using mutt version 1.2.5. Just tried that here. The bcc: header shows up in the fcc'ed copy. Do you have $write_bcc set? HTH, Michael -- Digital circuits are made from analog parts. -- Don Vonada PGP-Key: http://www-stud.ims.uni-stuttgart.de/~tatgeml/public.key
Re: Mutt and HTML body
Jacques Giudicelli [EMAIL PROTECTED] wrote: im quite a new user for Mutt. I would like to send a mail with a html body, how could i do that. I have tried a header with Content-Type : text/html but it doesn't work. You could compose your message as plain text and then from the compose menu (the one you're in when you have to send your message) hit 'F' to filter your message through something like txt2html (search on Freshmeat) and then edit the content-type into text/html by hitting ctrl-t. You could of course use a macro and bind it to for instance ctrl-h to do the filtering as well as the content-type editing: macro compose \ch "filter-entrytxt2html.plenteryedit-type\cutext/htmlenter "send a message in html" Regards, Morten
scoring
Hi, is it possible to do scoring in mutt (like in slrn) ? Would be useful for ML's with large bandwidth. -- Johannes
Folder-Hook to purge??
Hi to all! I've been experimenting for a while to archieve the automatical purging of mailing-lists' folders and found an unusual (bug|feature): I'm using the following: folder-hook =mutt 'push T~d14d!~T\nd' It works also, BUT: when I enter the folder "mutt", all the old messages are "marked for death" _including_ the most recent one. That means, if I have just received a message from John Doe, then it would be marked with D also... :((( Can anybody confirm this? Maybe someone knows a workaround? TIA Nikolai.
Re: courier-mta, mutt and PGP
At 15:49 +0100 05 Dec 2000, Anand Buddhdev [EMAIL PROTECTED] wrote:
On Tue, Dec 05, 2000 at 08:31:43AM -0500, Sam Varshavchik wrote:
Note that the second MIME section does not specify its content transfer
encoding. Neither is the default transfer encoding specified in the top
level MIME header. As I mentioned, if a MIME section that does explicitly
specify its transfer encoding, Courier will calculate one.
The default transfer encoding is never specified in the top level
header, it's specified in RFC (2045, section 6.1):
"Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
Please point out where it is stated that the top level encoding is
supposed to be the default for lower levels? The only mentions of a
default encoding that I can find in either RFC 2045 or 2046 is the one
quoted below and a couple in 2046 about the message/partial and
message/external-body types which also state that 7BIT is the default.
So the problem boils down to the MUA not generating full and correct MIME
headers. In this case, mutt isn't inserting all the headers that courier
expects (it assumes that the relevant information will be infered according
to RFC 1847). I suppose mutt's interpretation of the RFC is understandable.
Mutt's MIME headers *are* correct and as full as necessary. I don't see
any reason (other than broken software) for mutt to explicitly state
that a default value is to be used. So as far as can see mutt's
interpretation is not only understandable, it is correct.
of the MUA. Do you have any suggestions for alternative mail clients that
have better MIME support? Alternatively, do the mutt users have any ideas
on making mutt generate the headers as Sam suggests?
I'm not aware of mail clients with better MIME support (other than
possibly having builtin support for more types). I don't think it's
really even possible, since mutt's support is excellent.
But, I suppose you could use the attached patch to work around courier's
bad behaviour, it will cause mutt to always generate a
Content-Transfer-Encoding header for multipart/signed messages. The
same shouldn't be necessary for multipart/encrypted, since the relevant
headers are encrypted and therefore safe from courier. This patch is
against the CVS version, but I expect it will work for pretty much any
version.
--
Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/
Life is like sendmail: It's complicated and hard to understand,
but it sure beats the alternative. -- Paul Tomblin
--- sendlib.c.dist Tue Dec 5 12:31:21 2000
+++ sendlib.c Tue Dec 5 14:32:25 2000
@@ -433,7 +433,10 @@
fputc ('\n', f);
- if (a-encoding != ENC7BIT)
+ /* Courier MTA will rewrite messages that don't contain an explicit
+ * Content-Transfer-Encoding, breaking PGP/MIME signatures. */
+ if (a-encoding != ENC7BIT
+ || (a-type == TYPEMULTIPART mutt_strcmp(a-subtype, "signed") == 0) )
fprintf(f, "Content-Transfer-Encoding: %s\n", ENCODING (a-encoding));
/* Do NOT add the terminator here!!! */
quoting bug?
I have the user fro"hlich He tries to subscribe to a mailinglist, so he does echo | qmail-inject [EMAIL PROTECTED] He receives a confirmation request with From: [EMAIL PROTECTED] Reply-To: +"mw-dir-sc.976052641.bajogknapkbddkofkdco-fro\"hlich=thales.memphis.edu"@thales +.memphis.edu When he presses `r' for reply, he is prompted with the address in the From: field To: [EMAIL PROTECTED] Why? Nevertheless, I copy the address "mw-dir-sc.976052641.bajogknapkbddkofkdco-fro\"hlich=thales.memphis.edu"@thales..memphis.edu in the To: field and press RET, but mutt just aborts (does not prompt me with the Subject:). I think mutt removes the backslash from \", and then it terms the address incorrect. To confirm this, I create the user fr"o"hlich, who is also doing echo | qmail-inject [EMAIL PROTECTED] He receives the confirmation request with Reply-To: +"mw-dir-sc.976054041.enbpfcnbmdnkgjaimmpl-fr\"o\"hlich=thales.memphis.edu"@thal +es.memphis.edu when he presses `r' to reply, he is prompted with the following address "mw-dir-sc.976054041.enbpfcnbmdnkgjaimmpl-fr"o"hlich=thales.memphis.edu"@thales.memphis.edu which is invalid. So you see mutt removes the backslash from \". Why? Thx Mate
Re: Recording Bcc fields in fcc copy
On Mon, Dec 04, 2000 at 08:10:01PM +0100, Michael Tatge wrote: Julian Gilbey muttered: [Please cc replies to me!] I want to save any Bcc headers I have used in copies of mail I save to file using the Fcc: feature. Mutt seems to strip them before it saves the mail to file, which is really annoying. Is there any way I can do this? (Haven't found any mention of this behaviour in the docs.) I'm using mutt version 1.2.5. Just tried that here. The bcc: header shows up in the fcc'ed copy. Do you have $write_bcc set? Thanks! I thought I had (default is set, and I hadn't changed it), so I was bemused. But it turns out that Debian switches it off by default as exim doesn't remove the Bcc header before sending out the message. Duh. At least I know where I stand now. So thanks for the pointer. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: scoring
Johannes Zellner proclaimed on mutt-users that: is it possible to do scoring in mutt (like in slrn) ? Would be useful for ML's with large bandwidth. yes from the sample.muttrc - unscore * # score pattern value # at that entry. If you prefix the score with an equal sign (=), the score #score '~f ^me@cs\.hmc\.edu$' 1000 #score '~t mutt | ~c mutt' =500 #score '~f aol\.com$' - -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI Avoid Quiet and Placid persons unless you are in Need of Sleep. -- National Lampoon, "Deteriorata"
Re: scoring
On Wed, Dec 06, 2000 at 10:42:52AM +0530, Suresh Ramasubramanian wrote: Johannes Zellner proclaimed on mutt-users that: is it possible to do scoring in mutt (like in slrn) ? Would be useful for ML's with large bandwidth. yes from the sample.muttrc - [...] ahh, yes. Thanks. Now: is it possible to /show/ the scores ? -- As far as I understand this, scoring is just one of the sort methods. Now suppose I want to sort threaded, but want to have some marker (like the `!' in slrn) to show which messages have a high score. Is something like this possible ? -- Johannes
Re: Folder-Hook to purge??
Nikolai Prokoschenko wrote: : Hi to all! : : I've been experimenting for a while to archieve the automatical : purging of mailing-lists' folders and found an unusual : (bug|feature): : I'm using the following: : : folder-hook =mutt 'push T~d14d!~T\nd' : : It works also, BUT: when I enter the folder "mutt", all the old : messages are "marked for death" _including_ the most recent one. : That means, if I have just received a message from John Doe, then : it would be marked with D also... :((( Can anybody confirm this? : Maybe someone knows a workaround? TIA All right since you use ~d pattern what is date-sent. If you want to use date-received -- use ~r pattern instead. -- Andrew W. Nosenko([EMAIL PROTECTED])
