Ken Hornstein writes:
> My larger point is that, sadly, I've seen a distressing number of times
> when the text/plain version of a multipart/alternative message is not
> useful. I really wish people who have a shitty text/plain part would
> simply NOT bother and just generate text/html; I don't
Hi Tom,
> > sed 's/$/\n/' "$@" |
>
> Another idiom is: sed -eG.
Oh yes, that's better.
> > fmt -su |
>
> Interesting switches for fmt.
Well, I thought you could play around with what you prefer.
It's GNU fmt, which has annoying behaviour. Bring back _Software Tools_!
$ yes foo | f
Hi Jón,
> Ken writes:
> > I've seen a distressing number of times when the text/plain version
> > of a multipart/alternative message is not useful.
Yesterday's fun was working out why a `reset your password' URL didn't
work. Fill in the web page, submit, `Please correct the highlighted
errors',
Ken wrote:
> I don't know why they
> even bother to generate such a lousy text/plain part, but this is the
> world we live in.
One airline based in America sends empty (just the newline)
text/plain parts in their purchase confirmation messages:
$ mhlist -noheader
65 multipart/alternative
On Fri, 25 May 2018 20:39:26 -0400 Ken Hornstein sez:
> >Count me as another one of those few people who actually uses the
> >text/plain content. :-) For the most part, I don't read emails that are
> >HTML only unless I absolutely have to and if there's a text/plain I
> >manage with
Hi,
Michael Richards, message ID <2726.1527268876@localhost>:
~
> And given EFAIL, it seems that we were wise.
Or not? I've been surprised by the odd bit of decoding nmh has done for
MIME parts, giving a text summary of the content. I suspec
Hello, list,
I use msmtp as my sendmail program, and keep my configuration file in a
nonstandard place. I tried including this in mh_profile as follows:
send: -mts sendmail/pipe -sendmail "/usr/bin/msmtp -C /path/to/rc"
however, send is interpreting -C as an argument to istself, rather t
Hi Eduardo,
> send: -mts sendmail/pipe -sendmail "/usr/bin/msmtp -C /path/to/rc"
>
> however, send is interpreting -C as an argument to istself, rather than taking
> everything between quotes as the argument to -sendmail. Is this expected?
Yes, unfortunately. mh_profile(5) says
Shell
Thank you Ralph. Sorry for missing that in the docs.
--
Eduardo Alvarez
ealva...@fastmail.com
On Sat, May 26, 2018, at 11:42 AM, Ralph Corderoy wrote:
> Hi Eduardo,
>
> > send: -mts sendmail/pipe -sendmail "/usr/bin/msmtp -C /path/to/rc"
> >
> > however, send is interpreting -C as an a
Michael Richardson writes:
> And given EFAIL, it seems that we were wise.
nmh wise? I dunno. Part of EFAIL was that the mail client downloaded
bits from the Internet and interleaved them seamlessly into the message.
That seems like an inherently dangerous thing to do... and nmh does it
with one of
Hi Anthony,
> Part of EFAIL was that the mail client downloaded bits from the
> Internet and interleaved them seamlessly into the message.
IIRC it was that different adjacent parts were catenated if both
text/html before being sent to something to interpret the HTML. This
meant the join could pr
Ralph wrote:
> Hi Anthony,
> > How do I disable this behavior
>
> Possibly by nobbling nmh-access-url in an mhn.defaults, e.g. /etc/nmh,
Or, add these to your profile:
nmh-access-ftp: echo ^[[31\;1mSuppressed loading of
nmh-access-url: echo ^[[31\;1mSuppressed loading of
The ANSI control seque
>Michael Richardson writes:
>> And given EFAIL, it seems that we were wise.
>
>nmh wise? I dunno. Part of EFAIL was that the mail client downloaded
>bits from the Internet and interleaved them seamlessly into the message.
>That seems like an inherently dangerous thing to do... and nmh does it
>with
Ken Hornstein writes:
> Respectfully ... the vulnerability with EFAIL was NOT that people downloaded
> stuff via HTTP.
I suppose I shouldn't say that *was* the vulnerability; but if mail
clients didn't fetch URLs embedded in the mail by default, EFAIL would
not have been possible.
> To the larger
14 matches
Mail list logo
