Re: Inline PGP Within HTML
On Tue, Apr 28, 2020 at 12:18:14AM -0500, David Engel wrote: > On Mon, Apr 27, 2020 at 01:46:26PM -0400, Scott Kostyshak wrote: > > On Mon, Apr 27, 2020 at 12:32:05PM -0500, Derek Martin wrote: > > > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote: > > > > I've given up politely asking people to remember to send email as > > > > either both text/html and text/plain or just text/plain when sending > > > > to me. It's a losing battle. :( > > > > You've given up *politely* asking? Meaning you are now asking > > impolitely? :) > > I do have to keep working with these people. :) > > > > Yeah, I've been trying to explain this to some folks around here > > > recently, but not having much success. You have my sympathy. > > > > Agreed. It is frustrating. But Derek, please don't give up! Even in the > > worst case scenario, we can slow the acceleration. I especially take the > > time to choose the battles where the email is from an automated system. > > I contact the support and send something like the following: > > > > Could you please modify your automatic emails to also send a > > plain-text version in addition to the HTML email? This is easy to do > > and most professional emails provide a plain text version (this is > > called multi-part MIME). > > > > If this doesn't make sense to you, please forward this request to your > > tech team. > > > > Thanks for your time! > > I have essentially done this but the problem keeps reoccurring. I > think part of the problem might be Outlook itself. I vaguely recall > seeing something about Outlook only sending both text/plain and > text/html when those are the only two parts. If another attachment is > included, I seem to recall that one of the text parts got dropped. I > could be wrong, though. > > I'm considering trying the polite approach again but this including > the pointer to the integrated solution I tested. Maybe I can start > the change from the bottom up. Makes sense. Good luck! Scott
Re: Inline PGP Within HTML
On Mon, Apr 27, 2020 at 01:46:57PM -0600, Akkana Peck wrote: > > > > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote: > > > > I've given up politely asking people to remember to send email as > > > > either both text/html and text/plain or just text/plain when sending > > > > to me. It's a losing battle. :( > > Since I don't have to deal with PGP, increasingly I wish people > would just send HTML and dispense with the text/plain. Lynx or > similar programs work fine inside mutt for HTML mail (if there isn't > too much fancy formatting), I guess we disagree :) > but if there's a text/plain part, more > and more often it's blank, garbled or just unreadable because it > lacks any line breaks. True, this is worse than not sending a plain part. Actually, in this case at least you might realize that you should check for the HTML message. Even worse is if the plain has some info but not all, in which case you might not even realize there's a problem. > Scott Kostyshak writes: > > If this doesn't make sense to you, please forward this request to your > > tech team. > > I wish! But the "tech team" almost never has any idea what MIME > multipart/alternative is, and any attempt to convince them that > they're sending out garbled email just results in "It looks fine > to me and nobody else has complained." > > In fact, out of many complaints about such problems, I don't think > I've *ever* gotten an answer like "Oh, thanks for letting me know, > I guess I never checked the plaintext part." It's been "looks fine > to me" every. single. time. And most of the time, no matter how many > times we go back and forth I can never manage to convince them even > that a text part exists, let alone that it's worth fixing. I have had similar troubles. Most of the time I don't get a response. But once in a while I come across a kind tech support person who is open to the idea and that makes up for the 10 non-responses so I keep trying. Scott
Re: Inline PGP Within HTML
On Mon, Apr 27, 2020 at 12:32:05PM -0500, Derek Martin wrote: > On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote: > > I've given up politely asking people to remember to send email as > > either both text/html and text/plain or just text/plain when sending > > to me. It's a losing battle. :( You've given up *politely* asking? Meaning you are now asking impolitely? :) > Yeah, I've been trying to explain this to some folks around here > recently, but not having much success. You have my sympathy. Agreed. It is frustrating. But Derek, please don't give up! Even in the worst case scenario, we can slow the acceleration. I especially take the time to choose the battles where the email is from an automated system. I contact the support and send something like the following: Could you please modify your automatic emails to also send a plain-text version in addition to the HTML email? This is easy to do and most professional emails provide a plain text version (this is called multi-part MIME). If this doesn't make sense to you, please forward this request to your tech team. Thanks for your time! Best, Scott
Re: Bottom posting v top posting
On Sun, May 13, 2018 at 03:23:45AM +, Ian Zimmerman wrote: > I also bottom post with some of my best friends who _are_ gmail users, > and they don't object. +1 The key, I've learned, is to teach them about bottom-posting. I have occassionally used bottom-posting with contacts without warning, and that has led to some confusion. I now try to remember to put "see my responses in-line below" as the first line of the message. Some mail clients by default collapse inline responses. I don't know which mail clients they are, but contacts have told me that they just saw an empty email (until I told them to search for how to uncollapse the quoted reply). To me, this is a clear bug in such mail clients, but it's good to know the behavior exists. I think the important thing is to be kind and patient with newcommers, and educate them on why in some situations some people prefer bottom-posting. I do not participate on this list much, but on lyx-users bottom-posting is part of our "list netiquette" [1]. If I see a user who is sticking around for a while, I just kindly remind them that it is part of our list netiquette. If everyone takes turns in patiently reminding newcommers, it is not so much of a hastle and I've found that the newcommers are open to bottom-posting. Scott [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.lyx.org_FAQ_ListNetiquette=DwIBAg=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM=zUqJVM3RY5svAe6ctaxqyrj3k9OQkcL6UzDF3Kn6e0s=I0V31ciCHXrUy7R-bTo1iUQ7IQ-O4anaqqzxuRkujCM=l3XyQq-DSjJT-wVddDp5jQhsRavz1QC53Zxx3JUIpqQ= -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/
Re: Reply with another email as attachment?
On Wed, Mar 14, 2018 at 12:48:56PM +, David Woodfall wrote: > I have recently been in a discussion with a tech support person about > some emails that I have been receiving and I was asked to attach one > of them to a test email that she sent me. > > I couldn't find how to do that, apart from actually finding the file > and attaching it that way. When I pressed 'a' to attach and then '?' > for a list I had a list of my folders up, but mutt wouldn't let me enter > them and gave a 'couldn't attach ' error. > > Is there a way of doing this? I have no idea if the following is good advice or not, but I'll mention it and let you investigate, unless the other method works well for you. You can "bounce" an email with the "b" key. The advantage of this is that I believe the recipient will see the email just as you saw it. i.e. all of the headers will be the same. When you attach an email (as per the other solution), I'm not sure the headers are preserved. The disadvantage is that the email will look strange if the person is not expecting it (because the To: header will be to you!), so you should always warn the recipient (in my case, usually a tech team). Best, Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/
Re: html signature?
On Thu, Mar 08, 2018 at 08:29:47AM +, Thomas Stein wrote: > On 2018-03-08 08:47, Yubin Ruan wrote: > > On Thu, Mar 08, 2018 at 12:40:26AM -0500, Scott Kostyshak wrote: > > > I find that one reason that they seem particularly responsive to is > > > to point out that people with disabilities may have trouble with > > > HTML-only emails. > > Why? > > One example: Many visually impaired computer users read mails using either a > screen reader[1] or a braille display[2]. Both devices are known to work > best with plain text. That is what I had in mind also. This is at least what a visually impaired student told me. That was 5 years ago though, perhaps technology has improved to the point where it is not a big problem anymore. The following does not give a detailed explanation, but it does recommend at least a plain-text email version: https://urldefense.proofpoint.com/v2/url?u=https-3A__litmus.com_blog_accessibility-2Demail-2Ddesign-2Dinfograph=DwIBAg=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM=zUqJVM3RY5svAe6ctaxqyrj3k9OQkcL6UzDF3Kn6e0s=4rdeU5UU5g6LLY2dMJjydI1hJxXXucFFbKggnvD3cjM=E1g96DB0nLqgGwdHwF5VTs7hMPt47bng45d0wpY2x2E= I personally find images and color distracting when trying to focus completely on the content of an email. To be fair, getting rid of images and color makes my focus level go from e.g. 95% to 98%, but I do find it significant. I can imagine (but speak on no authority) that people who have disabilities related to attention and focus would have similar difficulty with distracting and unnecessary elements. Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/
Re: html signature?
On Wed, Mar 07, 2018 at 10:21:24PM +, Matthias Apitz wrote: > Sorry, I meant: > > In case of real text/plain part (and not only 'click here to read this > mail' or other suggestions the like) I do READ them. Many of the HTML-only emails come from automated email systems. I usually respond and explain to them why I would appreciate a plain-text email. I list a few reasons. I find that one reason that they seem particularly responsive to is to point out that people with disabilities may have trouble with HTML-only emails. At the bottom of the email, I always tell them to forward my suggestion to their tech team. It takes time to write these emails, and is frustrating, but I find that some are actually responsive to it. Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/
Re: html signature?
On Wed, Mar 07, 2018 at 07:02:50PM +, Grant Edwards wrote: > On 2018-03-07, Scott Kostyshak <skostys...@ufl.edu> wrote: > > On Tue, Mar 06, 2018 at 08:06:12PM +, Grant Edwards wrote: > >> > >> I've noticed that the handling of text/plain by popular GUI MUAs has > >> gotten so bad in past few years, that I'm now reluctant to send mail > >> in that format. > > > > What are the most common mistakes? > > They don't use a fixed-width font. I suppose it's debatable as to > whether that's a "bug", but it wrecks a lot of plaintext posts/emails > that have columns of data or "tables" in them. > > Some of them start a new paragraph (complete with extra vertical > space) everytime they see a cr/lf. > > Or, they wrap things like bullet lists into a single "paragraph": > > This is a list with three items > * item 1 > * item 2 > * item 3 > > But it shows up like this: > > This is a list with three items * item 1 * item 2 * item 3 > > text/plain (which usually assumes an 80-colum display) often renders > especially bad on narrow phone displays. > > > I wasn't aware of this situation, and since I often argue in favor > > of text/plain (well, usually multi-part MIME), I should be aware of > > these issues. > > It depends on what MUAs (and the versions) the recipients have. Thanks, Grant and Tim for your explanations. That's good to know! Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/
Re: html signature?
On Tue, Mar 06, 2018 at 08:06:12PM +, Grant Edwards wrote: > > I've noticed that the handling of text/plain by popular GUI MUAs has > gotten so bad in past few years, that I'm now reluctant to send mail > in that format. What are the most common mistakes? I wasn't aware of this situation, and since I often argue in favor of text/plain (well, usually multi-part MIME), I should be aware of these issues. Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/
Re: Color headers in pager based on message patterns
On Wed, Feb 07, 2018 at 10:00:33PM +, Cameron Simpson wrote: > On 07Feb2018 01:05, Scott Kostyshak <skostys...@ufl.edu> wrote: > > I would like to color all header lines in the pager if a message pattern > > matches. > > > > As an example, I can use the following to color the index if a message > > was sent to me and not sent to a list: > > > > color index yellow black ~p!~l > > > > But I cannot do the following: > > > > color header yellow black ~p!~l > > > > to color all headers in the pager if a message was sent to me and not > > sent to a list. This is understandable, as the pattern is matched > > against each header. > > > > As for why I would like to do this, I rarely look at the index. I > > configure mutt to go directly to the pager, so that I focus on one email > > at a time. However, I find the message pattern matching useful so I > > would like to be able to use them to color headers in the pager. > > > > Is it possible to use the message pattern mechanism to color headers > > showing in the pager? > > Yes, you need to be a little indirect. > > My setup has these lines: > > color header $colour_hl1 default "^(from|subject):" > color header $colour_hl1 default "^(x-spam-status):" > > Where $colour_hl1 happens to be cyan. What you want to do is, instead of > defining your header rules once, define them per message via a message-hook. > Example (untested): > > message-hook . 'set my_hdr_colour=green' > message-hook ~p!~l 'set my_hdr_colour=yellow' > message-hook . 'color header $my_hdr_colour default' > > so that a colour is chosen per message, then applied to your settings. > > Cheers, > Cameron Simpson <c...@cskk.id.au> (formerly c...@zip.com.au) I think that does the trick! I had to change the last of the three hooks to be the following (note the dot at the end): message-hook . 'color header $my_hdr_colour default .' Thank you very much for taking the time to understand what I was trying to achieve, and for the helpful solution, Cameron. Best, Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/
Color headers in pager based on message patterns
I would like to color all header lines in the pager if a message pattern matches. As an example, I can use the following to color the index if a message was sent to me and not sent to a list: color index yellow black ~p!~l But I cannot do the following: color header yellow black ~p!~l to color all headers in the pager if a message was sent to me and not sent to a list. This is understandable, as the pattern is matched against each header. As for why I would like to do this, I rarely look at the index. I configure mutt to go directly to the pager, so that I focus on one email at a time. However, I find the message pattern matching useful so I would like to be able to use them to color headers in the pager. Is it possible to use the message pattern mechanism to color headers showing in the pager? Thanks, Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/
Re: Possible to not leave pager if up on first or down on last message?
On Fri, Dec 22, 2017 at 03:49:11PM +, Ben Boeckel wrote: > On Fri, Dec 22, 2017 at 19:38:15 +1100, Erik Christiansen wrote: > > On the contrary, Ben's key bindings do keep you in the pager, > > substituting line up/down for message up/down. (It's something which > > I've also adopted long ago, as the default is alien.) > > They're Todd's, not mine :) . It makes it move lines, but if you want to > move to the next message, I don't think there's away to say "move to the > next message unless this is the last one" and similarly for the first > message. Thanks, Ben and Erik. I should have been more specific. Indeed, as Ben mentions I would still like to use the default navigation across messages (I like using Return/backspace within messages), I just wanted to change only that one behavior of and . Scott
Re: Possible to not leave pager if up on first or down on last message?
On Wed, Dec 20, 2017 at 09:00:34PM +, Todd Zullinger wrote: > Ben Boeckel wrote: > > On Wed, Dec 20, 2017 at 14:14:38 -0500, Todd Zullinger wrote: > >> I think you want the pager_stop? variable: > >> > >> 3.169. pager_stop > >> > >> Type: boolean > >> Default: no > >> > >> When set, the internal-pager will not move to the next > >> message when you are at the end of a message and invoke > >> the function. > > > > That's for internal page navigation. Pressing or is an index > > operation and doesn't affect Scott's issue. (This is the setup I have > > now and Up/Down still close the pager for me.) > > Oops, sorry about that. I also have some key bindings to > remap and which I didn't remember. > > bindpager previous-line > bindpager next-line > > I knew this sort of thing used to bug me and when I looked > at pager_stop in my muttrc, I thought that was it. It's > been many years since I set most of these things. My memory > is obviously not as clear as I'd like to think. ;) > > -- > Todd > ~~ > Fleas can be taught nearly anything that a Congressman can. > -- Mark Twain > Thank you for the replies, Todd and Ben. It seems there's not a configuration variable for what I would like to achieve. Scott
Possible to not leave pager if up on first or down on last message?
When I'm in the pager and on the first message, if I accidentally press it takes me to the index, with a message of "You are on the first message". This makes sense, but I would prefer to stay in the pager. Similarly for pressing on the last messsage, I would prefer to stay in the pager. Is it possible to configure this? My use case is I find it very helpful to be able to focus on one email at a time, without knowing how many emails I have. I start mutt with: mutt -e "push " Best, Scott
Re: Speed
I don't know if it's an option for your situation, but you might consider offlineimap. For a folder of size about 1000, it took 2 seconds to open it. Of course, this is after using offlineimap to download the messages locally. Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/ On Tue, Oct 24, 2017 at 06:48:31PM +, David Woodfall wrote: > Thanks I'll give that a shot. > > > On Tue, Oct 24, 2017 at 06:43:03PM +0100, David Woodfall wrote: > > > I've been using mutt a fair while now. Lately I've been using it with > > > imap and find that it can take a while to read headers. > > > > > > Are there any tricks to speeding up imap? > > > > > > I do have a header cache, but it still takes some time opening a > > > folder with a 1000+ or so messages. > > > > > > Any tips? > > > > Switching to `lmdb` backend made a significant speed upgrade difference for > > me.
