On 2012-12-01, Jamie Paul Griffin wrote:
>
> ... and I agree completely. As I wrote, I now wrap my lines and will
> make extra effort to ensure message formatting conforms so they are
> more readable. I don't like upsetting people, and I have taken on
> board all the valid and sensible points rais
On 2012-12-01, Rado Q wrote:
>=- Jamie Paul Griffin wrote on Sat 1.Dec'12 at 8:38:57 + -=
>
>> Long lines != the end of the world. Simple as that.
>
> ... _for you_.
> But it can mean the beginning of the end for efficient
> communication, when everybody starts caring less and less for it by
On 2012-11-30, Derek Martin wrote:
>
> I agree; good reasons for the existing standards have been put
> forth. Arguments against those standards and said reasons have
> contained fallacious logic.
This is the first such claim. No one has yet called out any fallacy
in logic with regards to allow
On 2012-11-30, Gray Calhoun wrote:
>>
>>Etiquette varies based on the domain (e.g. where you are). There is
>>not one single etiquette for the universe. In Japan, tipping is often
>>regarded as extremely offensive. In the US, tipping is often
>>expected.
>
> This is true, etiquette varies with
On 2012-11-30, Rich Kulawiec wrote:
>
> I have heard myriad arguments advanced for abandoning or modifying
> email etiquette over the past ten, twenty, thirty years. None of
> them have ever been accompanied by a convincing rationale that
> demonstrates why the proposed changes are substantive im
On 2012-11-27, Jamie Paul Griffin wrote:
>
> I'm sorry but you've lost me again :-) - both of you
There are two kinds of people:
1) Those who oppose ambiguity
2) Those who are wrong
Now those who oppose ambiguity want quotes to be trimmed, with a
direct reply underneath so there is no ambig
On 2012-11-26, Chris Bannister wrote:
>> "Waste" is something that in itself has no value. But formatting has
>> value added to the presentation. So it's a stretch to label html as
>> "waste", before even discussing the significance of it.
>
> I don't see how an html email adds any value whatsoe
On 2012-11-25, Chris Bannister wrote:
>
> With regards to mailing list posts, which is what the original post
> of mine was addressing, sending HTML posts is very wasteful. They
> are archived in various places on the Net, where they are stored for
> ever and a day. Yeah, yeah, hard disks are chea
On 2012-11-24, Patrick Shanahan wrote:
> * Tony's unattended mail [11-24-12 15:58]:
>> Again, this is another straw man. What I am suggesting is not the
>> format=flowed standard. It's a hypothetical hybrid.
>>
>> Saying that people will violate a stan
On 2012-11-24, Derek Martin wrote:
>
> It's not a straw man, because format=3Dflowed is functionally
> identical to what you're suggesting in every way, except that you
> are imposing an ADDITIONAL constraint that a specified number of
> line feeds MEANS something. THIS CAN NOT WORK. I've alread
On 2012-11-24, Patrick Shanahan wrote:
> * Peter Davis [11-24-12 15:09]:
>>
>> On 11/24/12 12:49 PM, Derek Martin wrote:
>>
>> >The convention for e-mail is 72 characters.
>> No. That was the convention. Currently, I don't believe there is one,
>> "convention" in this case meaning the predomina
On 2012-11-24, Derek Martin wrote:
>>=20
>> The number of consecutive newlines distinguishes the two. Two
>> newlines marks the end of a paragraph, and one newline marks the end
>> of monospaced text.
>
> Only if the user writes them that way. I receive a lot of flowed
> e-mail at work from cert
On 2012-11-24, Derek Martin wrote:
>
> Yeah, I said exactly that in another message. Now generate HTML
> mail with Mutt. Plus you still get a lot of folks -- many of whom
> use GUI clents -- who complain about HTML mail for any number of
> reasons. And at least a few of them are legitimately ar
On 2012-11-24, Derek Martin wrote:
>
> But how will the client decide what to monospace, and what not to?
> There is no discerning factor... in both cases you just have lines
> of text which are terminated by a newline.
The number of consecutive newlines distinguishes the two. Two
newlines marks
On 2012-11-24, Derek Martin wrote:
>
> On Fri, Nov 23, 2012 at 09:47:46PM +, Tony's unattended mail wrote:
>> > It's been pointed out that this number comes from scientific studies
>> > regarding the ergonomics of reading.
>>=20
>> Sure, but n
On 2012-11-24, Jim Graham wrote:
>>
>> By "variable width format", I mean a text message with unwrapped
>> paragraphs (which only has EOLs when semantically necessary).
>
> Ok, but the question still applies. if a table, for example, is typed
> in a fixed-width 72--76 column format, such as the
On 2012-11-23, Jim Graham wrote:
> On Fri, Nov 23, 2012 at 09:47:46PM +0000, Tony's unattended mail wrote:
>
>> BTW, sending a variable width format allows for 72 character
>> rendering, so these dated ergonomics studies are not at odds with an
>> unwrapped source t
On 2012-11-23, Derek Martin wrote:
>
> On Thu, Nov 22, 2012 at 06:17:27PM +, Tony's unattended mail wrote:
>> > At this time, the generally accepted assumption is to wrap at around
>> > 72--76 characters
>>=20
>> Right.. one million smokers can't
On 2012-11-21, Jim Graham wrote:
> On Wed, Nov 21, 2012 at 05:02:50PM +0000, Tony's unattended mail wrote:
>
>> LF means "begin next line now". So as an author posting text to a
>> forum, at what point do you need an LF? Not after XX width,
>> becaus
On 2012-11-21, Rado Q wrote:
>
> I guess you put too much interpretation/ meaning in plain-text/
> "text/plain": LF is just that, nothing else, 2 LF are a paragraph,
> that's it.
"Too much" interpretation is an odd stance to take. It's a necessary
amount of interpretation in order to understand
On 2012-11-20, Patrick Shanahan wrote:
>
> Original text is fine unwrapped, but should not be sent that way. You
> should not impose on the reciever but sent mat'l in a manner that would be
> presented as one *should* expect.
Recipients should not impose on composers. Otherwise Larry would
dema
On 2012-11-20, Rado Q wrote:
> The same argumentation applies to producing "readable" mail:
> why fix something on the reader-end when it could/should be fixed at
> the source?
To say that you can only have a convention that's mindful of the
source XOR the target is to create a false dichotomy.
On 2012-11-20, Rado Q wrote:
>=- David Young wrote on Tue 20.Nov'12 at 11:59:55 -0600 -=
>
>> "What, you have computers in your pockets but there is no
>> conformance to the width in columns of 40 year-old data terminals
>> any more?"
>
> That's not a technical issue but readability: it's easier o
On 2012-11-20, John Long wrote:
>
> The tools are fine Outlook, AOL, google groups, it's pretty much
> all about thumbing your nose at the world and saying you don't give
> a rat's a$$ about the other guy.
Outlook actually illustrates my point. Good tools interpret the
mail-followup-to heade
On 2012-11-20, John Long wrote:
>
> I use slrn, probably the best all around news reader out there and
> it doesn't wrap unless you tell it. But even that looks bad.
slrn's problem. Slrn (which I sometimes use as well) should do
better.
> You can't make a sloppy pile of HTML or run-on sentences
On 2012-11-20, Chris Bannister wrote:
>
> Ouch! Could you please set the "line wrap" value in your editor to a
> sane value? 72 characters seems to be the recommended setting.
That was the recommendation in the 90s.
These days, any decent news reader has word wrap. Considering the
variety of wi
On 2012-11-18, Woody Wu wrote:
> I want to read/post the list in gmane.org. So I want to ask, if the
> list (mutt-users) allow users to subscribe but without send messages to
> their mailbox?
Sadly, the mutt list forces users to subscribe. Consequently, the
red-tape forces gmane users to subscr
> However, I find dovecot deliver (which uses the sieve language
> for filtering) to be much more readable/writable than procmail.
Sieve does not include regular expressions -- I shit you not.
Dovecote needs regular expression capability to be shoe-horned in by
some hokey plugin. Regular expres
On 2012-10-28, Remco Rijnders wrote:
>
> While it is not an answer to your original question, would it not work if=
>=20
> you added your own root certificate with smime_keys add_root ? Then it=20
> should hopefully accept your own certificate too.
Thanks for the suggestion. That was actually on
Due to a bug in mutt, I will begin using gnus for some things
(e.g. self-signed S/MIME certs). The question is, can mutt and gnus
both be used to access the same set of mbox files?
Are there any unhandled race-condition-like pitfalls with having both
tools work on mbox files simultaneously?
Has anyone figured out how to add keys for S/MIME without using the
smime_keys script?
I suspect smime_keys is just a wrapper script and everything can
probably be done using openssl. Due to my lack of PERL skills,
and this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690255
I am blo
31 matches
Mail list logo
