Re: overriding the charset for headers
On Wed, Aug 28, 2002 at 05:24:44PM +0200, Sven Guckes wrote: > > That is why I think it would be much better to have manual charset > > override for headers, just like the one we have for bodies. > > IMHO, this functionality should be implemented in MUA. > > this would only work around the problems > created by bad mail clients, wouldn't it? Yes, and "only" would be sufficient for me :) . > > However, mutt is the best MUA > > with regard to bad input tolerance. I think it > > lacks this feature, which is already implemented > > in the source, but is inapplicable to headers. I > > somehow the prospect of mutt becoming a repair tool for > the brokenness of other mailers does not make me happy. With respect for your opinion. However, I like mutt especially for these features, and I think such features give it flexibility -- mutt's main strength, IMHO. > i'd rather tell other users to not use the broken > mailers at all and thereby let them die. > life's too short for bad software. Life's too short to convince all users of bad software :) . So, let me restate my question: I'm looking for a local way to convert unquoted or malquoted headers. I would greatly appreciate any help regarding the pipes, or Japanese patches doing header conversion, or any method that would work with IMAP mailboxes. Thanks in advance, Baurjan.
Re: LC_CTYPE vs. charset (il)logic (was: Re: overriding the charset for headers)
On Wed, Aug 28, 2002 at 09:03:14AM -0700, Sam Peterson wrote: > Try keeping your locale to en_US.ISO8859-1. I think, provided > LC_CTYPE allows for 8-bits, you should be able to set $charset to > something different from LC_CTYPE, without problems. At least, I'm > able to do this with $charset=euc-jp. Me, too -- I've got fully functional setup thanks to mutt developers, Debian package maintainers and Marco d'Itri, Debian mutt maintainer. I had asked just an explanation _why_ mutt displays characters that way. With kind regards, Baurjan.
Re: display-address and display-subject
On Wed, Aug 28, 2002 at 05:12:41PM +0200, Sven Guckes wrote:
> extract the Subject line with "grep":
> macro index S "grep -i '^subject:'\n"
Didn't work for me; could that happen due to the inbox being an IMAP
one?
> change the display of the folder index:
> macro index S ":set index_format="%3C %{%b %d} %s"
This one worked, thanks much :) !
However, piping seems to be better since it would show the full line,
even if it is longer than the terminal width. Any idea why it didn't
work?
Besides, seems that I can use it to convert an unquoted subject to
another encoding.
With kind regards,
Baurjan.
LC_CTYPE vs. charset (il)logic (was: Re: overriding the charset for headers)
On Tue, Aug 27, 2002 at 01:37:30PM -0700, Sam Peterson wrote: > > I'm using 1.4. I think LC_CTYPE and charset are set correctly in both > > cases. BTW, why does Mutt use both of these variables? I would find > > logical if charset have overridden LC_CTYPE. I can't see the rationale > > behind the current implementation, and find it counter-intuitive. Could > > anyone please shed some light on this, too? > > Hmm, from my experience, charset does override LC_CTYPE. I'll have to > double check that. To my knowledge, charset is set based on your > locale if you don't explicitly set it in your muttrc. Anyone? Example: let's take a message encoded in iso-8859-1 and containing the character 'รง' (LATIN SMALL LETTER C WITH CEDILLA, octal code 347). The following table outlines how the message is displayed with different LC_CTYPE and charset values on a system with (hopefully) properly configured locales (mutt 1.4.0-2 on Debian unstable): LC_CTYPE charset user wants mutt shows user expects --- -- -- "" "" unknown \347? "" iso-8859-1 iso-8859-1 \347ccedilla "" us-asciius-ascii ? ? en_US.US-ASCII "" us-ascii \347? en_US.US-ASCII iso-8859-1 iso-8859-1 \347ccedilla en_US.US-ASCII us-asciius-ascii ? ? en_US.ISO-8859-1 "" iso-8859-1 ccedillaccedilla en_US.ISO-8859-1 iso-8859-1 iso-8859-1 ccedillaccedilla en_US.ISO-8859-1 us-asciius-ascii ? ? Here LC_CTYPE and charset are the environment and mutt variables, respectively. "Mutt shows" column lists what mutt is actually displaying. "User wants" and "user expects" show what I call "override": the charset to be assumed by mutt given the two variable values, and the character that, IMHO, should be displayed by mutt according to the charset assumed. Apparently, mutt does the following: * display ccedilla if it can be displayed both with LC_CTYPE and charset; * display ? if char can't be displayed with charset, regardless of LC_CTYPE value; * display \347 if char can be displayed with charset, but can't be displayed with LC_CTYPE. At the moment, I can see neither any useful application of ? and \347 distinction, nor the relation between LC_CTYPE and charset -- I certainly cannot call it "override". Seems to me as if it was some side effect of code layering inside mutt. And the logic I propose is: 1. if charset is set, assumed_charset = charset; otherwise, if LC_CTYPE is set, assumed_charset = LC_CTYPE; otherwise, assumed_charset = "us-ascii". 2. * display ccedilla if it can be displayed with assumed_charset; * display ? if it can't. I don't insist my scheme is "better" since I don't know the rationale behind the current design. However, I see much user confusion with this issue and think it could be made more simple, more stupid the way I've desribed. What do you think? With kind regards, Baurjan. P.S. I can see the full address in index mode using "@". Can I see the full subject?
Re: overriding the charset for headers
On Tue, Aug 27, 2002 at 01:37:30PM -0700, Sam Peterson wrote: > > My console can display koi8-r. I receive a mail encoded in windows-1251 > > with an unquoted header. Mutt converts the body to koi8-r, and I can > > read the contents. However, Mutt doesn't know the header charset, so it > > is displayed without conversion, and I can't read it. For instance, 192 > > is Acyr in 1251, but I see it as yucyr with my koi8-r font. > > > > I wish I could specify the header charset manually (as I do with ^E for > > message bodies) so that Mutt could convert the subject and other fields. > > Using procmail/formail and iconv you might be able to accomplish > rewriting of the mail headers based on the sender so they are properly > escaped. I've looked at procmail a while ago for body translation, but couldn't find a working solution. 1. All three inboxes I use are IMAP; how can I use procmail with it? I can define a macro that would do what I want, but how would it take the input, and where it should store the output? 2. Matching the messages by From: or To: isn't reliable since the same person can send messages in different encodings. E.g., message from a web-based client can be encoded in koi8-r and flagged as iso-8859-1, and message from a windows-based MUA can be encoded in windows-1251 and flagged as iso-8859-1. Let alone rare cases where the same person can send mail either in koi8-r or in iso-8859-9, both tagged as us-ascii. 3. What to do with raw 8-bit data in headers? I can't see how one can have formail convert it to quoted-printable. Of course, I can use other converters like iconv, but it would need to know current display charset and my guess about the message charset. Let's assume I can pass the former on ($charset) via the command line, and the latter is read from the keyboard; what about #1 above? That is why I think it would be much better to have manual charset override for headers, just like the one we have for bodies. IMHO, this functionality should be implemented in MUA. > Bottom line is, those senders are using broken mail clients. Though it > may seem anti-social, ya might want to drop a few hints to this. I > don't think mutt's the only mail client that would get confused by > such email. I completely agree. However, mutt is the best MUA with regard to bad input tolerance. I think it lacks this feature, which is already implemented in the source, but is inapplicable to headers. I would be happy to see it implemented. > * ^From: Evil Sender <[EMAIL PROTECTED]> In my case, it is brokenmailclients.com ;) . Thank you, I'll try that if I can find a way to execute that with a message on a remote mailbox. With kind regards, Baurjan.
Re: overriding the charset for headers
On Tue, Aug 27, 2002 at 03:44:08PM -0500, Aaron Schrab wrote: > > message, how can one have Mutt set To: and/or Cc: fields automatically > > (Mail-Followup-To: contains both sender and list addresses)? "r" and "L" > > set To: only. > > Let me guess, you're trying this with a message you sent? Yes, that was the case. Now I see I can use "L" to do that with others' mail. Thanks much! With kind regards, Baurjan.
Re: overriding the charset for headers
On Tue, Aug 27, 2002 at 08:06:00PM +0300, Baurjan Ismagulov wrote: > P.S. Please cc to me, I'm not subscribed. > I have "lists mutt-users" and "set followup_to" in my .muttrc, but > I can't see any Followup-To: lines in the mail sent. Oops, turns out that Mutt sets Mail-Followup-To: upon sending, this field doesn't appear in postponed folder. Having received such a message, how can one have Mutt set To: and/or Cc: fields automatically (Mail-Followup-To: contains both sender and list addresses)? "r" and "L" set To: only. With kind regards, Baurjan.
overriding the charset for headers
Hello,
this has been discussed in the past, but I couldn't find an adequate
solution for my particular problem.
I often receive messages with either unquoted 8-bit headers (in lines
like From:, To:, Subject:, etc.) or, worse, with characters quoted and
wrong charset specified.
Example 1:
My console can display koi8-r. I receive a mail encoded in windows-1251
with an unquoted header. Mutt converts the body to koi8-r, and I can
read the contents. However, Mutt doesn't know the header charset, so it
is displayed without conversion, and I can't read it. For instance, 192
is Acyr in 1251, but I see it as yucyr with my koi8-r font.
I wish I could specify the header charset manually (as I do with ^E for
message bodies) so that Mutt could convert the subject and other fields.
Example 2:
My console can display iso-8859-9. I receive a mail encoded in
iso-8859-9. Headers are quoted, and the charset is set to iso-8859-1
("Subject: =?iso-8859-1?Q?some_8859-9-encoded_text?=). Mutt reads the
charset, and displays 8859-9-specific characters as question marks, as
they are not present in my 8859-9 font. E.g., 254 is scedilla in 8859-9,
but Mutt thinks it is 8859-1, and tries to display thorn, which is not
available in the font.
Again, the only solution I see is to override the charset manually. I
can't just "charset-hook iso-8859-1 iso-8859-9" since I can as well
receive mail encoded in koi8-r, but flagged as iso-8859-1.
I'm using 1.4. I think LC_CTYPE and charset are set correctly in both
cases. BTW, why does Mutt use both of these variables? I would find
logical if charset have overridden LC_CTYPE. I can't see the rationale
behind the current implementation, and find it counter-intuitive. Could
anyone please shed some light on this, too?
I would appreciate any help.
Thanks in advance,
Baurjan.
P.S. Please cc to me, I'm not subscribed.
I have "lists mutt-users" and "set followup_to" in my .muttrc, but
I can't see any Followup-To: lines in the mail sent.
Re: the trouble with charset Windows-1252
On Fri, Dec 07, 2001 at 07:11:40PM +0100, Cristian wrote: > It looks like I haven't made myself very clear. My point is that even > if the Content-Type is set `correctly' to Windows-1252, there are > still some characters that appear as question marks but should (in my > opinion) rather be converted to iso-8859-1 quotes or dashes, for > instance. Iconv does not do this for me. Hmmm... That was what I understood from your previous post: > aren't they? The problem is, many Windows user send bogus Content-Type > header lines, so where the line should read, > Content-Type: text/plain; charset=Windows-1252 > I often find, > Content-Type: text/plain; charset=iso-8859-1 > or even, > Content-Type: text/plain; charset=us-ascii > instead. > As a consequence, overriding the charset does not help me. As far as I could understand, you complain, among other things, about mutt displaying some characters from messages encoded in windows-1252, as question marks, if your charset is set to iso-8859-9? I think this is what iconv library functions are for; my mutt performs conversions between charsets I use without problems (including transliteration). If you send me an example message, pointing out the "funny" characters and how they should look, I'll look whether I can help. With kind regards, Baurjan.
Re: Strange characters. (encoding?)
Hello,
On Sun, Dec 09, 2001 at 06:28:10PM -0500, Brian Clark wrote:
>
> Can some kind soul point me to the docs I need to read to figure out why
> I see things like this:
>
> \251 allie\260M
>
> In some messages? \260 is the degree symbol and \251 is the copyright
> symbol, I think.
Seems that this is the product of mutt's idea of which characters are
displayable using your current charset. What is encoding of the message
(you can see it using the "v" key) and your current charset (":set
charset")? I think you can check whether the symbols would
display correctly on your terminal with something like "echo -e '\251'"
(single quotes are important), if your echo supports "-e" switch.
With kind regards,
Baurjan.
Re: OT: procmail recipe for two actions for a message?
Hello, On Mon, Dec 10, 2001 at 12:22:00AM +0100, Benjamin Michotte wrote: > Is it possible to set something like > > :0: > * ^(To|Cc).*linux@lists\.linuxbe\.org > * ^(To|Cc).*linux@lists\.unixtech\.be > linux Seems that this will match only messages sent to both lists, which is probably not what you want. What about :0 * ^(To|Cc).*linux@lists\.(linuxbe\.org|unixtech\.be) linux I'm new to procmail, so please test. Hope this helps, Baurjan.
Re: the trouble with charset Windows-1252
Hello, thanks all for your suggestions. I hadn't used procmail before, so I've read some manuals. Using the default spool mailbox, .forward and procmail recipe like :0 w: $DEFAULT.lock * ^mailing-list: .*yahoogroups * ^content-type: text/plain; charset=us-ascii | formail -i "Content-Type: text/plain; charset=iso-8859-9" >>$DEFAULT I get charset fixed as needed (although I'm not sure about the proper locking). But in reality I use two mailboxes, both are IMAP. On one of the servers I don't have shell access, so I can't use procmail (?). The other one is Cyrus, with its own LDA and non-mbox mailbox format. I have yet to look whether (and how) I can use .forward and formail there (tips appreciated). My question is: can I do the same with mutt only? E.g., I open the mailbox, press on a message, and (optionally) if it matches a certain criterion, it gets filtered through an external program, then displayed in usual mutt's viewer? Thanks in advance, Baurjan. On Thu, Dec 06, 2001 at 11:43:50PM +0100, Michael Wagner wrote: > you can solve this problem with procmail. In "man procmailex" ist an > example for piping a message through formail to correct the charset. I > think, this is the best you can do, because you can give all mails > which you get, the charset you want.
Re: the trouble with charset Windows-1252
On Fri, Dec 07, 2001 at 07:11:40PM +0100, Cristian wrote: > It looks like I haven't made myself very clear. My point is that even > if the Content-Type is set `correctly' to Windows-1252, there are > still some characters that appear as question marks but should (in my > opinion) rather be converted to iso-8859-1 quotes or dashes, for > instance. Iconv does not do this for me. Hmmm... That was what I understood from your previous post: > aren't they? The problem is, many Windows user send bogus Content-Type > header lines, so where the line should read, > Content-Type: text/plain; charset=Windows-1252 > I often find, > Content-Type: text/plain; charset=iso-8859-1 > or even, > Content-Type: text/plain; charset=us-ascii > instead. > As a consequence, overriding the charset does not help me. As far as I could understand, you complain, among other things, about mutt displaying some characters from messages encoded in windows-1252, as question marks, if your charset is set to iso-8859-9? I think this is what iconv library functions are for; my mutt performs conversions between charsets I use without problems (including transliteration). If you send me an example message, pointing out the "funny" characters and how they should look, I'll look whether I can help. With kind regards, Baurjan.
Re: the trouble with charset Windows-1252
Hello, On Thu, Dec 06, 2001 at 06:02:53PM +0100, [EMAIL PROTECTED] wrote: > Right, that's what the excellent programs iconv and recode are for, I also suffer from the same problem. In such cases, I don't use any external programs; instead, I "v"iew-attachments, "^E"dit-type, and override the charset. Hope this helps. However, I have two problems with this approach: 1. I can't save the change. If I move the message with overridden charset into another folder, it returns to the original state. 2. It doesn't scale. I'm subscribed to a list, where 99% of messages are broken like described above, from a POP account. When I "G" fetch-mail, it's a pain to fix each message. Does anyone know how to solve these, especially the second one? Can I make mutt automatically override charset of messages matching a certain criterion (e.g., "To: .* ")? Thanks in advance, Baurjan.
Re: the trouble with charset Windows-1252
Hello, On Thu, Dec 06, 2001 at 06:02:53PM +0100, [EMAIL PROTECTED] wrote: > Right, that's what the excellent programs iconv and recode are for, I also suffer from the same problem. In such cases, I don't use any external programs; instead, I "v"iew-attachments, "^E"dit-type, and override the charset. Hope this helps. However, I have two problems with this approach: 1. I can't save the change. If I move the message with overridden charset into another folder, it returns to the original state. 2. It doesn't scale. I'm subscribed to a list, where 99% of messages are broken like described above, from a POP account. When I "G" fetch-mail, it's a pain to fix each message. Does anyone know how to solve these, especially the second one? Can I make mutt automatically override charset of messages matching a certain criterion (e.g., "To: .* ")? Thanks in advance, Baurjan.
transliteration
Hello, I'm using mutt 1.3.23i with libiconv 1.7.0.1 on RedHat 6.2. I couldn't find any references to libiconv mailing list, private mail to the maintainer bounced; I was unable to find any relevant info from mutt-users arhives, too. That's why I'm writing here. I'm happy to see that mutt 1.3 has substantially better encoding handling (especially proper conversion). I "./configure --enable-pop --enable-imap --with-ssl --enable-locales-fix --without-wc-funcs" and have no problems displaying mail in various encodings. However, very often I have to read mail (encoded in koi8-r, windows-1251, or iso-8859-9) from 7-bit dumb terminals. In such cases I have to use transliteration. But I don't like new default transliteration scheme. With ":set charset=us-ascii//translit", Cyrillic letters are either printed incorrectly (e.g., they look as 8-bit garbage) or are not printed at all. Turkish "extra" letters (with codes > 127) are printed as "o, ^u, etc., whereas they are traditionally used without prepending diaeresis or circumflex (i.e., like plain o, u, etc.). I made some changes to libiconv-1.7.0.1/lib/translit.def (a patch is attached) and issued "make -f Makefile.devel lib/translit.h; make clean; make install" (I didn't know whether cleaning was necessary, just to be sure). This worked for iso-8859-9, but not for Cyrillic encodings: they still show up as garbage, or are not showed at all. Could anyone please point how I can solve the problem? If the issue is libiconv-related, what is the current address of the maintainer or the mailing list? Thanks in advance, Baurjan. libiconv-1.7.0.1-ibr.2000-1713.gz Description: application/gunzip
charsets during redraw
hi, thanks for all replies regarding pop password forgetting. i understand the necessity of using fetchmail, and i plan to switch to it later. currently i implement quick-and-dirty solution, which is to set pop_pass to a dummy value and then unsetting it. now i've got another problem. i'm using iso-8859-9 and koi8-r simultaneously. the same folder can contain messages with both encodings. i switch between encodings using macros. this includes font and keyboard layout switching. 1. if my current charset is iso-8859-9, mutt renders subjects written in koi8-r so that they are readable using that charset (e.g., russian characters are translated into english ones). this is a Good Thing. if i change font/charset, message subjects continue to be rendered as before -- transliterated -- although charset (and font) are now suitable for displaying "natively" (in koi8-r). ^L doesn't change that, i have to change the folder to itself to make mutt discard cached rendering style (based on previous charset). what is the proper way to achieve that? 2. can we specify multiple translation maps? or should i change the source? as far as i can see, the mapping is one-to-one, i.e. single russian character must be mapped into a single english character. this produces disgusting output -- for example, russian "ya" is mapped to "j", etc. i'm very used to good old koi-7, although some may find it unreadable. so i'm looking for a way to replace current mapping scheme, be it multiple translation maps or replacing the default map. any ideas? thanks in advance, baurjan.
Re: forget pop password
> > i have to use two pop servers. i switch between them using macros. i need mutt to >forget the pop password. any ideas? > Would it be an idea to use fetchmail for local delivery ? IMHO it's simpler ;) yeah, seems that i'll have to do that... i never have time to do the things properly, but i spend plenty of it debugging ;( . thanks, baurjan.
forget pop password
hi, i have to use two pop servers. i switch between them using macros. i need mutt to forget the pop password. any ideas? thanks in advance, baurjan.
alternates in reverse_alias
hi, i've searched the archive but couldn't find anything related: most of my correspondents use more than one address to write to me. i want to reverse_alias them so the index looks uniformly. i don't want to setup aliases for each address. is there a way to list them in a single place, similar to alternates? for example, mail can come from: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] i want all these addresses to resolve to "akram". thanks in advance, baurjan.
quick charset toggle
hi, i have to change my charset frequently. currently, i'm typing ":set c=" (occasionally, "charset" is the first keyword completed). but after that i have to type "iso-8859-9" and "koi8-r" manually each time, which is quite annoying. how can i speed up this process? btw, i still can't mix two languages in the single message. mime gurus? thanks in advance, baurjan.
Re: From_ line
hi,
thank you all for the responses.
to summarize:
the From_ line is used in mbox folder format to specify the beginning of the [next]
message. makes sense -- mutt shows my message split into pieces if it contains lines
starting with "From " in its body. seems that there's nothing specifying the format of
the line itself, although sendmail does write the envelope ("MAIL FROM:") address
(source: cf/README from sendmail-8.10.1) and the time when the message was transferred
to mda (just guess, it is a couple of seconds later than the time stated in the
"Received:" field).
why did i want to preserve it?
my "Received:" fields are normally turned off, and i wanted to see the time the
message arrived to my server without toggling headers view.
besides, i wanted to see whether the envelope-from address would make spam tracking
easier. Anton, how did you enable envelope-from in the "Received:" field? via
confRECEIVED_HEADER? or could you please send your sendmail.cf via private mail?
thanks again,
baurjan.
Re: From_ line
i'm pretty sure this is not mda problem since i can check the mailbox on the server just before fetching the mail; it contains the correct line, which gets corrupted after i suck it to the "client" (i.e., my desktop machine) with mutt. your experience with fetchmail makes me think that it is rather a "feature" of one of the related protocols (pop3 or smtp message format in general (is there such a thing?)). could anyone confirm (or, better, deny)? best regards, baurjan. > | my problem is NOT "how to show/hide specific headers", but rather "how to retain >the original From_ line". for instance: when the message arrives to the mail server >(sendmail 8.10.1 and mail.local from solaris 7), the From_ line in the mailbox >(/var/mail/ibr) looks like > | >From [EMAIL PROTECTED] Tue Jun 6 10:33:24 2000 > | > | then i fetch the message using mutt's built-in pop3 support (i set pop_user, >pop_host, and pop_delete). the From_ line becomes: > | >From ibr Tue Jun 6 10:18:29 2000 > | > > I haven't yet used the built in pop support, but intend to read up on it > some more. However, I am using fetchmail, and the same issue occurs. And > it is for this reason that I would think this has to do with the > Delivery Agent, and not the Reader, mutt, or what have you.
Re: From_ line
hi, thanks for the reply. sorry for inconvenience, forgot to escape From_ lines. seems that i've been somewhat unclear in stating the problem. my problem is NOT "how to show/hide specific headers", but rather "how to retain the original From_ line". for instance: when the message arrives to the mail server (sendmail 8.10.1 and mail.local from solaris 7), the From_ line in the mailbox (/var/mail/ibr) looks like < From [EMAIL PROTECTED] Tue Jun 6 10:33:24 2000 then i fetch the message using mutt's built-in pop3 support (i set pop_user, pop_host, and pop_delete). the From_ line becomes: > From ibr Tue Jun 6 10:18:29 2000 the question is, can i see its original state, i.e., can i see < From [EMAIL PROTECTED] Tue Jun 6 10:33:24 2000 (the original sender and the original send time) in mutt? best regards, baurjan. On Tue, Jun 06, 2000 at 10:21:13AM -0700, [EMAIL PROTECTED] wrote: > If you are speaking of the first from line, I believe this is handled by > the Mail Delivery Agent, like Sendmail, or Qmail. You can use the ignore > option to rid of this... > > > # Flush Headers > unhdr_order * > hdr_order From Newsgroups: From: Reply-To: To: Cc: Subject: Date: Message-Id: >X-Mailer: X-Newsreader: X-Agent: > > On Tue, Jun 06, 2000 at 10:49:21AM +0300, Baurjan Ismagulov muttered: > | hi, > | > | i'm using mutt-1.2i with pop3. when i fetch messages from the server, they are >stored into the local mailbox with corrupted (well, from my point of view) From_ >line. below is an example: > | the line > | < From [EMAIL PROTECTED] Tue Jun 6 10:33:24 2000 > | becomes > | > From ibr Tue Jun 6 10:18:29 2000 > | (where ibr is my unix username and 10:18 is the time when i fetched the mail). > | > | i'm aware that mutt's pop3 support is rather limited, but what is the reason for >such substitution? can i get the original From_ line without using other tools (like >fetchmail, recommended in doc/manual.txt)? - End forwarded message -
Re: From_ line
hi, thanks for the reply. seems that i've been somewhat unclear in stating the problem. my problem is NOT "how to show/hide specific headers", but rather "how to retain the original From_ line". for instance: when the message arrives to the mail server (sendmail 8.10.1 and mail.local from solaris 7), the From_ line in the mailbox (/var/mail/ibr) looks like >From [EMAIL PROTECTED] Tue Jun 6 10:33:24 2000 then i fetch the message using mutt's built-in pop3 support (i set pop_user, pop_host, and pop_delete). the From_ line becomes: >From ibr Tue Jun 6 10:18:29 2000 the question is, can i see its original state, i.e., can i see >From [EMAIL PROTECTED] Tue Jun 6 10:33:24 2000 (the original sender and the original send time) in mutt? best regards, baurjan. On Tue, Jun 06, 2000 at 10:21:13AM -0700, [EMAIL PROTECTED] wrote: > If you are speaking of the first from line, I believe this is handled by > the Mail Delivery Agent, like Sendmail, or Qmail. You can use the ignore > option to rid of this... > > > # Flush Headers > unhdr_order * > hdr_order From Newsgroups: From: Reply-To: To: Cc: Subject: Date: Message-Id: >X-Mailer: X-Newsreader: X-Agent: > > On Tue, Jun 06, 2000 at 10:49:21AM +0300, Baurjan Ismagulov muttered: > | hi, > | > | i'm using mutt-1.2i with pop3. when i fetch messages from the server, they are >stored into the local mailbox with corrupted (well, from my point of view) From_ >line. below is an example: > | the line > | < From [EMAIL PROTECTED] Tue Jun 6 10:33:24 2000 > | becomes > | > From ibr Tue Jun 6 10:18:29 2000 > | (where ibr is my unix username and 10:18 is the time when i fetched the mail). > | > | i'm aware that mutt's pop3 support is rather limited, but what is the reason for >such substitution? can i get the original From_ line without using other tools (like >fetchmail, recommended in doc/manual.txt)?
multilingual text
hi, can i create messages in two different languages using overlapping 8-bit charsets simultaneously? i need, for example, mix koi8-r and iso-8859-9 in one message. i'm afraid this is not related to mutt itself, but to standards like smtp/mime etc. could anyone confirm? thanks in advance, baurjan.
From_ line
hi, i'm using mutt-1.2i with pop3. when i fetch messages from the server, they are stored into the local mailbox with corrupted (well, from my point of view) From_ line. below is an example: the line < From [EMAIL PROTECTED] Tue Jun 6 10:33:24 2000 becomes > From ibr Tue Jun 6 10:18:29 2000 (where ibr is my unix username and 10:18 is the time when i fetched the mail). i'm aware that mutt's pop3 support is rather limited, but what is the reason for such substitution? can i get the original From_ line without using other tools (like fetchmail, recommended in doc/manual.txt)? thanks in advance, baurjan.
charset override
hi, how can i override the charset specified in the Content-Type: field of an incoming message? the problem is, some muas send 8-bit text in messages marked with charset=iso-8859-1. i'm using mutt-1.2i with --enable-locales-fix. i've looked into doc/manual.txt but seems that there's no such feature. thanks in advance, baurjan.
