In message ,
Conrad Hughes wrote:
> - replfilter depends on 'par', which users may not have installed, but
U... I don't have that either. What is it and where do I get it?
>Finally, I'd almost be inclined to have nmh-without-replfilter display a
>message about replfilter, for example
In message <20190627232032.737b9159...@pb-smtp1.pobox.com>,
Ken Hornstein wrote:
>>I had just sort-of jury-rigged my own very local and very idiosyncratic
>>mechanism for dealing with the problem/issue some years ago, and I have
>>been just trying to struggle along with it for all this time
> - replfilter depends on 'par', which users may not have installed, but
>the failure mode in its absence is suboptimal: the quoted text is
>absent, and the error shown on the command line is something like
>
> Pipe reader process exited with 72057594037927935
>
>.. could well be
Ken> As for repl(1), we've shipped with replyfilter in $(DOCDIR)/contrib
Ken> since 1.5 (released in 2012), and I use it on every message.
Just to say thanks for your patience on this: has been bugging me for a
while, and finally just sitting down and unpacking replfilter made a
huge difference.
>I had just sort-of jury-rigged my own very local and very idiosyncratic
>mechanism for dealing with the problem/issue some years ago, and I have
>been just trying to struggle along with it for all this time because
>I just haven't had the time to find a proper fix... which I've always
>assumed is
Ronald F. Guilmette wrote:
> Quite simply, all I would wish for would be something that would
-properly-
> convert -both- HTMLized emails -and- "Content-Transfer-Encoding: base64"
> emails (like this one I'm responding to) into good old fashioned ascii,
> at least for purposes
In message <20190627202344.7389f...@enterprise.home.antispaceman.com>,
spaceman wrote:
>All these in combination you end with a reasonable reply to HTML emails.
>The downside is that you don't get to keep the original email unless you
>make a copy of it and it's fairly hacky.
Thanks for all
Hi,
Ronald F. Guilmette wrote:
> Quite simply, all I would wish for would be something that would -properly-
> convert -both- HTMLized emails -and- "Content-Transfer-Encoding: base64"
> emails (like this one I'm responding to) into good old fashioned ascii,
> at least for purposes of the "show"
In message <20190627125114.70a3921...@orac.inputplus.co.uk>,
Ralph Corderoy wrote:
>Revisiting once again the issue of nice text from horrible HTML emails...
And here, all this time, I thought that it was just me! I assumed
that I had just failed to read the documentation well enough or long
>> Um, is it? I just looked at my copy, and it's there! And according to
>> the revision history that was added in 2016, and nmh 1.7 was released
>> in 2017 (and I didn't update the NEWS file for 1.7.1; dammit).
>
>Sorry, I should be more precise.
>The values which are valid for
Ken Hornstein wrote in <20190627175008.639987b...@pb-smtp21.pobox.com>:
|>Thinking about it, the "ext" in SSL_set_tlsext_host_name
|>could appear strange in five years from now.
|
|As opposed to the REST of the OpenSSL API? :-)
..seen that way.. But the problem is real:
#?0|kent:$ grep
Ken Hornstein wrote:
>> -authservice is missing from the inc.1 man page.
> Um, is it? I just looked at my copy, and it's there! And according to
> the revision history that was added in 2016, and nmh 1.7 was released
> in 2017 (and I didn't update the NEWS file for 1.7.1;
>-authservice is missing from the inc.1 man page.
Um, is it? I just looked at my copy, and it's there! And according to
the revision history that was added in 2016, and nmh 1.7 was released
in 2017 (and I didn't update the NEWS file for 1.7.1; dammit).
>I think that maybe we should have
>Thinking about it, the "ext" in SSL_set_tlsext_host_name
>could appear strange in five years from now.
As opposed to the REST of the OpenSSL API? :-)
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken Hornstein wrote in <20190627171410.ea24e7b...@pb-smtp21.pobox.com>:
|>I use that protected via
|>
|> #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
|
|I did see that ... but I also was worried that since OpenSSL makes no
|guarantees that this define will stick around in the future, depending
|on
Ken Hornstein wrote:
> It looks like Debian buster is the earliest version of Debian which has
> nmh 1.7.1. And it looks like that will be officially released next week.
> If you upgraded, would that be enough for you to switch away from
> fetchmail? :-) We support XOAUTH2!
I
I've made sure I am running 1.7 (from git), and I went through mhlogin
correctly. I pasted the result in, and then I did this with a second
account.
The token seems to be stored into Mail/oauth-gmail.
%inc -initialtls -host pop.gmail.com -user mcharl...@gmail.com -port pop3s
-snoop -sasl
>> And geez Mike, we talked about this a lot! Wasn't a secret!
>
>I read the man page. I wonder if my man pages are coming from debian, while
>my binaries are manually installed.
It looks like Debian buster is the earliest version of Debian which has
nmh 1.7.1. And it looks like that will
>I use that protected via
>
> #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
I did see that ... but I also was worried that since OpenSSL makes no
guarantees that this define will stick around in the future, depending
on that may come back to bite me. I'd rather simply just put it in
unconditionally and
Ken Hornstein wrote:
> When researching the issue Michael Richardson brought up today, it make
> me realize we really should be calling SSL_set_tlsext_host_name() so we
> send the TLS extension "server name indicator". Which is easy, it's
> literally one line of code. But that
Ralph Corderoy wrote:
>> I have used:
>>
>> fetchmail --verbose --sslcertpath="/etc/ssl/certs" --sslcertck
>> --proto POP3 --mda "rcvstore -sequence gmail +inbox"
>> --logfile /var/tmp/gmail.log pop.gmail.com
>>
>> to get my gmail downloaded for some time now.
>
>That would make RHEL6 users, at least, sad:
>
>$ rpm -q openssl
>openssl-1.0.1e-57.el6.x86_64
>openssl-1.0.1e-57.el6.i686
I feel your pain since we use a lot of CentOS 6 at work, but you don't
have much longer to use it, right? I think support for it only goes
until next year, unless you pay
Ken Hornstein wrote:
> And geez Mike, we talked about this a lot! Wasn't a secret!
I read the man page. I wonder if my man pages are coming from debian, while
my binaries are manually installed.
SNI === Server Name Indicator, which lets a server know which name
a client meant to connect
Ken Hornstein wrote in <20190627150420.4ff107a...@pb-smtp21.pobox.com>:
|Everyone,
|
|When researching the issue Michael Richardson brought up today, it make
|me realize we really should be calling SSL_set_tlsext_host_name() so we
|send the TLS extension "server name indicator". Which is
Ralph Corderoy wrote in <20190627125114.70a3921...@orac.inputplus.co.uk>:
|Revisiting once again the issue of nice text from horrible HTML emails,
|I found another textual web browser, like lynx(1), etc., but
|http://netrik.sourceforge.net/ uses colour in its --dump output.
|It doesn't list
Ken Hornstein writes:
> I think at this point we should consider OpenSSL
> 1.0.2 the minimum supported version of OpenSSL for nmh. This would
> guarantee we are doing TLS 1.2 everywhere and clean up some #ifdefs.
> Objections?
That would make RHEL6 users, at least, sad:
$ rpm -q openssl
>I think at this point we should consider OpenSSL
>1.0.2 the minimum supported version of OpenSSL for nmh. This would
>guarantee we are doing TLS 1.2 everywhere and clean up some #ifdefs.
>Objections?
One additional thing ... writing the code to check the version of
OpenSSL is a mild to moderate
>> It seems that fetchmail doesn't enable SNI for it's TLS connection
>
>Try adding `--sslproto TLS1' to fetchmail's arguments.
I guess the core issue is that for Google servers when using TLS 1.2 SNI
isn't required, but for TLS 1.3 it is; well, let me rephrase that. If
you negotiate TLS 1.3 you
ralph wrote:
> Hi Paul,
>
> > An obvious fix (for me) is to pre-process the digest, and
> > hyphen-escape all lines which follow the "END OF DIGEST" line and
> > which begin with a '-', by adding an extra '- ' at the start of line.
> > If I do that, then burst will do the right thing, and
>If I were to become extra-ambitious, and create a patch which added a
>"-endofdigest" switch which did something similar, would there be
>interest?
Yes ... but I would personally prefer if it was more generic. Like
if the -endofdigest switch took a regular expression, because as far
as I can
Hi Michael,
> I have used:
>
>fetchmail --verbose --sslcertpath="/etc/ssl/certs" --sslcertck
>--proto POP3 --mda "rcvstore -sequence gmail +inbox"
>--logfile /var/tmp/gmail.log pop.gmail.com
>
> to get my gmail downloaded for some time now.
Has your OpenSSL been upgraded
Hi Paul,
> An obvious fix (for me) is to pre-process the digest, and
> hyphen-escape all lines which follow the "END OF DIGEST" line and
> which begin with a '-', by adding an extra '- ' at the start of line.
> If I do that, then burst will do the right thing, and ignore all of
> the trailer
I'm on a list which, for historical reasons, is available only
in digest form. (Sigh.)
Like many digests, it includes hyphen-rich separator lines in the
trailing text of the digest, causing burst to create a flurry of
malformed messages when it parses according to RFC 934. Hoping for
the
Everyone,
When researching the issue Michael Richardson brought up today, it make
me realize we really should be calling SSL_set_tlsext_host_name() so we
send the TLS extension "server name indicator". Which is easy, it's
literally one line of code. But that makes me ask a larger question: we
>I don't think that inc has any TLS support.
You are incorrect! Supported as of 1.7 when the unified security framework
was implemented. From the NEWS file:
- Complete unification of network security support. All network protocols
(currently, POP and SMTP) have been refactored to use a
I have used:
fetchmail --verbose --sslcertpath="/etc/ssl/certs" --sslcertck --proto POP3
--mda "rcvstore -sequence gmail +inbox" --logfile /var/tmp/gmail.log
pop.gmail.com
to get my gmail downloaded for some time now.
It seems that fetchmail doesn't enable SNI for it's TLS connection, and
Hi,
Revisiting once again the issue of nice text from horrible HTML emails,
I found another textual web browser, like lynx(1), etc., but
http://netrik.sourceforge.net/ uses colour in its --dump output.
It doesn't list the URL destinations though, e.g. the noisy `[42]' that
links prefixes to the
37 matches
Mail list logo
