Discussion:
Curse you, L-Soft!
Add Reply
Paul Gilmartin
2017-08-07 17:20:02 UTC
Reply
Permalink
Raw Message
I can neither submit an SR to L-Soft nor rant on the L-Soft
mailing list because I'm not a registered L-Soft customer.
And no owner of a LISTSERV to which I subscribe seems interested
in championing my cause. So, I'll vent here (again).

Mostly about composing or replying via the Web interface.

o When I attempt to reply to a submitter rather than to the
list, my message is usually bounced by Rules at the
recipients MTA. It might help greatly if LISTSERV added
a proper "Sender:" header.

o A "&&" digraph is always escaped incorrectly.

o When I Reply and Quote a message submitted with base64 encoding,
the quoted text appears in unrendered base64. Sad!

o There's no option to compose using a monospaced font, making
composing tabular information such as code fragments needlessly
difficult.

Grrrr,
gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-08-07 18:07:10 UTC
Reply
Permalink
Raw Message
I can neither submit an SR to L-Soft nor rant on the L-Soft mailing list because I'm not a registered L-Soft customer.
I feel your pain. I also wanted to moan and b*tch about base 64 encoding amongst other things, but ...
o When I attempt to reply to a submitter rather than to the list, my message is usually bounced by Rules at the recipients MTA. It might help greatly if LISTSERV added a proper "Sender:" header.
Uh, I'm not understanding you? What is MTA? I only respond via web-page, not via my own e-mail client software like Outlook. Else, I just copy and paste the sender's address manually, a real PITA, but there is not really an alternative AFAIK.
o A "&&" digraph is always escaped incorrectly.
This is news to me. Hmmm interesting.
o When I Reply and Quote a message submitted with base64 encoding, the quoted text appears in unrendered base64. Sad!
I copy the text in a web page, then go to the page where I can compose a message and paste text and then finish my composing work. There is a IBM-MAIN member which text I always copy and paste, because of base64 encoding. You also complained about him in the past.
o There's no option to compose using a monospaced font, making composing tabular information such as code fragments needlessly difficult.
I usually use a Notepad to compose text with monospaced font in Notepad, then I paste that text in the compose window on the IBM-MAIn webpage composing page. The same goes for text in my 3270 emulator.

I agree all of above is a real PITA! But no complaining about that will help you or me or others.... Grrrrrrr...

But I have a gut feeling it is about the poster own e-mail attributes to L-Soft which causes much grief to you and perhaps others too.

I don't blame them too. Perhaps my OWN (and yours too) posting is causing trouble to them too...

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-08-07 18:53:34 UTC
Reply
Permalink
Raw Message
On Mon, 7 Aug 2017 13:08:20 -0500, Elardus Engelbrecht
Post by Elardus Engelbrecht
I can neither submit an SR to L-Soft nor rant on the L-Soft mailing list because I'm not a registered L-Soft customer.
I feel your pain. I also wanted to moan and b*tch about base 64 encoding amongst other things, but ...
Sometimes Base64 or other binary-safe encoding is required by RFC.
Post by Elardus Engelbrecht
o When I attempt to reply to a submitter rather than to the list, my message is usually bounced by Rules at the recipients MTA. It might help greatly if LISTSERV added a proper "Sender:" header.
Uh, I'm not understanding you? What is MTA? I only respond via web-page, not via my own e-mail client software like Outlook. Else, I just copy and paste the sender's address manually, a real PITA, but there is not really an alternative AFAIK.
MTA = Mail Transfer Agent

This is/are the SMTP server(s) used to move email around.

[snip]
Post by Elardus Engelbrecht
But I have a gut feeling it is about the poster own e-mail attributes to L-Soft which causes much grief to you and perhaps others too.
I don't blame them too. Perhaps my OWN (and yours too) posting is causing trouble to them too...
Using a fully RFC-compliant MUA can cause many problems for those who
use "cowboy coded" MUAs.

And to complete the email glossary:

MUA = Mail User Agent (your mail reader)

MDA = Mail Delivery Agent (the server from which your MUA downloads mail)
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Joel C. Ewing
2017-08-07 20:44:02 UTC
Reply
Permalink
Raw Message
Post by David W Noon
On Mon, 7 Aug 2017 13:08:20 -0500, Elardus Engelbrecht
Post by Elardus Engelbrecht
I can neither submit an SR to L-Soft nor rant on the L-Soft mailing list because I'm not a registered L-Soft customer.
I feel your pain. I also wanted to moan and b*tch about base 64 encoding amongst other things, but ...
Sometimes Base64 or other binary-safe encoding is required by RFC.
E.g, base64 can be required for the message body when message headers
say it is encoded with "charset=UTF-8" or some other 8-bit encoding and
it gets sent to a recipient mail server that responds it is unable to
support 8bitMIME. For that to happen implies some system in the chain
of servers handling the email is running software that is over a decade
old, or for some reason has deliberately been configured to disable
8bitMIME support. Then again maybe it's really a header of
"Content-Transfer-Encoding: 8bit" (some characters contain non-zero 8th
bit) that triggers the problem rather than just charset UTF-8, which
might explain the rareness of the problem despite common usage of UTF-8
these days.

It is highly unlikely the end user "submitted" the email using a base64
encoding of the message text, but rather that it was just submitted with
UTF-8 and some server in the path taken by the email to the ibm-main
list forced the usage of base64 to constrain the message to 7-bit
characters.

My email client (Thunderbird under Fedora Linux) sends charset UTF-8 by
default, but the headers also contain "Content-Transfer-Encoding: 7bit",
unless I actually include some UTF-8 characters that require a non-zero
8th bit, in which case it sends "Content-Transfer-Encoding: 8bit". I
know the messages I send to another of my email accounts with UTF-8 and
Transfer-Encoding 8bit do not get transformed to base64, nor do my
normal posts to IBM-main with charset UTF-8 and Transfer-Encoding 7bit.
As an experiment, I will try adding some "unusual" characters (like
degree ° and check__✔) to force Content-Transfer-Encoding: 8bit and see
what the list does to this message.__
Joel C. Ewing
...
--
Joel C. Ewing, Bentonville, AR ***@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin (π)
2017-08-07 22:27:52 UTC
Reply
Permalink
Raw Message
Post by Joel C. Ewing
As an experiment, I will try adding some "unusual" characters (like
degree ° and check__✔) to force Content-Transfer-Encoding: 8bit and see
what the list does to this message.__
(antiquated) MacOS Mail.app seems to force Q-P. On Linux, mutt seems
nicer, and ***@univie.ac.at respects and echoes that. I'll try:
Cc: ***@univie.ac.at
Content-Transfer-Encoding: 8bit
and see what happens.

Apologies for all the tests,
gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-08-07 21:23:40 UTC
Reply
Permalink
Raw Message
Post by Joel C. Ewing
As an experiment, I will try adding some "unusual" characters (like
degree ° and check__✔) to force Content-Transfer-Encoding: 8bit and see
what the list does to this message.__
It came to me as:
Content-Type: text/plain; charset=utf-8
...
Content-Transfer-Encoding: quoted-printable
Don't know which M?A did me the "favor". Pervasive timidity, almost phobic.

[How] does it appear in your outbox? Do you have REPRO ON?
how did it get reflected to you?

And when I mail something to a mainframe, it often arrives as:
charset=USASCII
when it has clearly been translated to EBCDIC. If a MTA/MDA is going
to perform such a conversion, it ought to adjust the MIME headers to
agree.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-08-08 06:44:14 UTC
Reply
Permalink
Raw Message
Post by David W Noon
Sometimes Base64 or other binary-safe encoding is required by RFC.
So I see. Thanks. Wish Shmuel is here, he certainly has something to say about all these RFC requirements...
Post by David W Noon
MTA = Mail Transfer Agent
This is/are the SMTP server(s) used to move email around.
Using a fully RFC-compliant MUA can cause many problems for those who use "cowboy coded" MUAs.
MUA = Mail User Agent (your mail reader)
MDA = Mail Delivery Agent (the server from which your MUA downloads mail)
Thanks for your kind help and the list of those glossary. I'll ask my SMTP colleague about this.

Thanks again! Much appreciated.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-08-08 16:50:40 UTC
Reply
Permalink
Raw Message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 8 Aug 2017 01:45:22 -0500, Elardus Engelbrecht (Elardus
Post by Elardus Engelbrecht
Post by David W Noon
Sometimes Base64 or other binary-safe encoding is required by RFC.
So I see. Thanks. Wish Shmuel is here, he certainly has something to
say about all these RFC requirements...
Shmuel Metz has something to say about almost everything. ... :-)

You might see this message encoded as Base64. I am including a
cryptographic signature and that usually requires a binary-safe
encoding.
Post by Elardus Engelbrecht
Post by David W Noon
MTA = Mail Transfer Agent
This is/are the SMTP server(s) used to move email around.
Using a fully RFC-compliant MUA can cause many problems for those
who use "cowboy coded" MUAs.
MUA = Mail User Agent (your mail reader)
MDA = Mail Delivery Agent (the server from which your MUA downloads mail)
Thanks for your kind help and the list of those glossary. I'll ask my
SMTP colleague about this.
Thanks again! Much appreciated.
My pleasure.
- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQQj5Jtua8i7AnGK26uiBiBwjhb/lAUCWYnrugAKCRCiBiBwjhb/
lL5CAKDT8paMZN7aHzjYKlkxniKHDRUteACeJlLOx2LiWzEuXaWQbrWlgk+eemA=
=b6P2
-----END PGP SIGNATURE-----

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-08-08 17:18:56 UTC
Reply
Permalink
Raw Message
(off-list)
Post by David W Noon
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 8 Aug 2017 01:45:22 -0500, Elardus Engelbrecht (Elardus
Post by Elardus Engelbrecht
Post by David W Noon
Sometimes Base64 or other binary-safe encoding is required by RFC.
So I see. Thanks. Wish Shmuel is here, he certainly has something to
say about all these RFC requirements...
Shmuel Metz has something to say about almost everything. ... :-)
You might see this message encoded as Base64. I am including a
cryptographic signature and that usually requires a binary-safe
encoding.
Indeed:
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=US-ASCII

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-08-08 14:15:08 UTC
Reply
Permalink
Raw Message
(sent via web interface)
Post by Elardus Engelbrecht
Post by David W Noon
Sometimes Base64 or other binary-safe encoding is required by RFC.
So I see. Thanks. Wish Shmuel is here, he certainly has something to say about all these RFC requirements...
According to various experiments and headers of off-list messages:

MacOS Mail.app sends utf-8 as quoted-printable but deals corectly with
incoming 8-bit/

From one set of mail headers:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

From another sent from Outlook/Windoze:
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

WTF!? Why encode us-ascii? 7bit should suffice. But every blank was encoded
as hex 20!?

A message I sent with mutt to IBM-MAIN; Cc: ***@univie.ac.at was reflected
by echo with an 8bit header so I assume that's what mutt uses. But IBM-MAIN
REPROed it as quoted-printable. Still phobic of 8bit.

A "non-blank blank" might be either a nonbreaking space or an en-space. 8bit
utf-8 should suffice for those; no need for base64.

RFC 822 limits records to 999 bytes, give or take a <CR><LF>. Longer records
require some encoding. But some MUAs, phobically, encode any message
containing records longer than 80 bytes. I blame a desire to accommodate
antediluvian IBM conventions for this compulsion.

And encoding might be needed to protect a "From" message separator. I
recall one MUA that encoded every "F" anywhere in a message as hex 46.
My first guess at its motivation was probably wrong.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-08-08 17:23:22 UTC
Reply
Permalink
Raw Message
On Tue, 8 Aug 2017 09:16:18 -0500, Paul Gilmartin (Paul Gilmartin) wrote
about Curse you, L-Soft!:

[snip]
Post by Paul Gilmartin
MacOS Mail.app sends utf-8 as quoted-printable but deals corectly with
incoming 8-bit/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Mutt has always been very RFC-compliant.
Post by Paul Gilmartin
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
WTF!? Why encode us-ascii? 7bit should suffice. But every blank
was encoded as hex 20!?
Microsoft sets the standards.
Post by Paul Gilmartin
reflected by echo with an 8bit header so I assume that's what mutt
uses. But IBM-MAIN REPROed it as quoted-printable. Still phobic of
8bit.
A "non-blank blank" might be either a nonbreaking space or an
en-space. 8bit utf-8 should suffice for those; no need for base64.
Another problem with a non-breaking blank is finding a MUA that
respects the non-breaking attribute.
Post by Paul Gilmartin
RFC 822 limits records to 999 bytes, give or take a <CR><LF>. Longer
records require some encoding. But some MUAs, phobically, encode any
message containing records longer than 80 bytes. I blame a desire to
accommodate antediluvian IBM conventions for this compulsion.
RFC 822 has been doubly obsoleted, by RFC 2822 and RFC 5322. The latter
specifies 998 bytes as the line limit with a CR/LF pair added to make
1000. It also recommends a limit of 78 bytes, plus CR/LF. This is why
lines of more than 80 bytes in total can induce encoding.
Post by Paul Gilmartin
And encoding might be needed to protect a "From" message separator. I
recall one MUA that encoded every "F" anywhere in a message as hex 46.
My first guess at its motivation was probably wrong.
The "From" separator is peculiar to Berkeley/Eudora mbox mail storage,
although there are many recensions of this. Anything else should not
escape this as ">From", even though some MDAs and even some MTAs do
this, but the usual culprit seems to be mailing list forwarders. I see
lots of paragraphs that begin with "From" that have been decorated to
">From" even though no mbox storage has occurred along the way.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-08-08 17:34:50 UTC
Reply
Permalink
Raw Message
Post by David W Noon
-----BEGIN PGP SIGNED MESSAGE-----
First time I see this prefix message with PGP and word MESSAGE. Hmmm, interesting. I really need to do drink coffee and then RTFM...
Post by David W Noon
Hash: SHA1
You're using SHA1, not SHA256? Ok, what e-mail software are you using. If you don't want to answer, this is fine with me.
Post by David W Noon
Shmuel Metz has something to say about almost everything. ... :-)
Hahahahahaha! LOL! ;-D

He [and Chris Mason] sometimes flamed me [privately] for every comment I make, but that is Ok with me, I just say "thank you" and move on.
Post by David W Noon
You might see this message encoded as Base64. I am including a cryptographic signature and that usually requires a binary-safe encoding.
Yes and I see this too: "-----BEGIN PGP SIGNATURE-----"

I don't remember I ever see that, but I can see your reply on IBM-MAIN properly, but when I "quote" your reply while composing my own reply to you and to IBM-MAIN via web-site, all your reply is encrypted.

I believe someone posted an URL where you can place that encoded message and that site can translate it for you into readable text.

David, please continue with your posts. I (and probably others too) learn and value your kind posts.

Thank you and all of the very best to you!

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-08-08 20:00:47 UTC
Reply
Permalink
Raw Message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 8 Aug 2017 12:36:00 -0500, Elardus Engelbrecht
[snip]
Post by Elardus Engelbrecht
Post by David W Noon
Hash: SHA1
You're using SHA1, not SHA256? Ok, what e-mail software are you
using. If you don't want to answer, this is fine with me.
The hash does not need to be particularly secure for signing, so SHA1 is
plenty good enough. Even MD5 can still be used.

I used Claws Mail to send that message. I am using Thunderbird to send
this one. Claws is much more RFC-compliant than Thunderbird.
Post by Elardus Engelbrecht
Post by David W Noon
You might see this message encoded as Base64. I am including a
cryptographic signature and that usually requires a binary-safe
encoding.
Yes and I see this too: "-----BEGIN PGP SIGNATURE-----"
I'll add a PGP signature to this message too. Thunderbird probably will
not encode it as Base64 as T'bird is not RFC-compliant (or at least not
as compliant as Claws). The only reason I do not use Claws all the time
is because it does not always play nice with the MDA I use.

SECOND ATTEMPT:
===============

LISTSERV does not accept messages signed with an attachment, only with
an inline signature. The first attempt was rejected by LISTSERV. So
we'll try again.
Post by Elardus Engelbrecht
I don't remember I ever see that, but I can see your reply on
IBM-MAIN properly, but when I "quote" your reply while composing my
own reply to you and to IBM-MAIN via web-site, all your reply is
encrypted.
I don't know what MUA(s) you are using, but I would feel inclined to use
something else if I were you.
Post by Elardus Engelbrecht
I believe someone posted an URL where you can place that encoded
message and that site can translate it for you into readable text.
All UNIX-like systems have command-line utilities to decode Base64 into
original text (or even binary).

It has been many years since I last used Windows. I don't think I could
live with its limitations these days.
- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


-----BEGIN PGP SIGNATURE-----

iHoEARECADoWIQQj5Jtua8i7AnGK26uiBiBwjhb/lAUCWYoYohwcZGF2aWQudy5u
b29uQGdvb2dsZW1haWwuY29tAAoJEKIGIHCOFv+UOIsAoLka/l+PWUvbLKC5fcAx
ve+/4TI5AJ9CskfP8ZF3m+5R+x1yr8zswW4ymQ==
=WN/U
-----END PGP SIGNATURE-----

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2017-08-09 12:28:57 UTC
Reply
Permalink
Raw Message
Before blaming L-Soft, it probably makes sense to be sure the list is
running current software. I know many lists are way backlevel...

On Tue, Aug 8, 2017 at 4:01 PM, David W Noon <
Post by David W Noon
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 8 Aug 2017 12:36:00 -0500, Elardus Engelbrecht
[snip]
Post by Elardus Engelbrecht
Post by David W Noon
Hash: SHA1
You're using SHA1, not SHA256? Ok, what e-mail software are you
using. If you don't want to answer, this is fine with me.
The hash does not need to be particularly secure for signing, so SHA1 is
plenty good enough. Even MD5 can still be used.
I used Claws Mail to send that message. I am using Thunderbird to send
this one. Claws is much more RFC-compliant than Thunderbird.
Post by Elardus Engelbrecht
Post by David W Noon
You might see this message encoded as Base64. I am including a
cryptographic signature and that usually requires a binary-safe
encoding.
Yes and I see this too: "-----BEGIN PGP SIGNATURE-----"
I'll add a PGP signature to this message too. Thunderbird probably will
not encode it as Base64 as T'bird is not RFC-compliant (or at least not
as compliant as Claws). The only reason I do not use Claws all the time
is because it does not always play nice with the MDA I use.
===============
LISTSERV does not accept messages signed with an attachment, only with
an inline signature. The first attempt was rejected by LISTSERV. So
we'll try again.
Post by Elardus Engelbrecht
I don't remember I ever see that, but I can see your reply on
IBM-MAIN properly, but when I "quote" your reply while composing my
own reply to you and to IBM-MAIN via web-site, all your reply is
encrypted.
I don't know what MUA(s) you are using, but I would feel inclined to use
something else if I were you.
Post by Elardus Engelbrecht
I believe someone posted an URL where you can place that encoded
message and that site can translate it for you into readable text.
All UNIX-like systems have command-line utilities to decode Base64 into
original text (or even binary).
It has been many years since I last used Windows. I don't think I could
live with its limitations these days.
- --
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-----BEGIN PGP SIGNATURE-----
iHoEARECADoWIQQj5Jtua8i7AnGK26uiBiBwjhb/lAUCWYoYohwcZGF2aWQudy5u
b29uQGdvb2dsZW1haWwuY29tAAoJEKIGIHCOFv+UOIsAoLka/l+PWUvbLKC5fcAx
ve+/4TI5AJ9CskfP8ZF3m+5R+x1yr8zswW4ymQ==
=WN/U
-----END PGP SIGNATURE-----
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
zMan -- "I've got a mainframe and I'm not afraid to use it"

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-08-08 17:51:28 UTC
Reply
Permalink
Raw Message
Post by David W Noon
Mutt has always been very RFC-compliant.
Meaning both that it obeys the rules in the RFCs and doesn't invent any
of its own.
Post by David W Noon
Microsoft sets the standards.
I'm mad as hell, and I'm not going to take it anymore!
Post by David W Noon
Another problem with a non-breaking blank is finding a MUA that
respects the non-breaking attribute.
Sigh. That might be more of the OS's text viewer than of the MUA itself.
Post by David W Noon
RFC 822 has been doubly obsoleted, by RFC 2822 and RFC 5322. The latter
specifies 998 bytes as the line limit with a CR/LF pair added to make
1000. It also recommends a limit of 78 bytes, plus CR/LF. This is why
lines of more than 80 bytes in total can induce encoding.
That strikes me as a cowardly accommodation to broken MUAs such as
VM's RSCS. But even that can be configured to deliver messages in
NETDATA format rather than printer spool images. An overzealous
application of Postel's Principle.
Post by David W Noon
Post by Paul Gilmartin
And encoding might be needed to protect a "From" message separator. I
recall one MUA that encoded every "F" anywhere in a message as hex 46.
My first guess at its motivation was probably wrong.
The "From" separator is peculiar to Berkeley/Eudora mbox mail storage,
although there are many recensions of this. Anything else should not
escape this as ">From", even though some MDAs and even some MTAs do
this, but the usual culprit seems to be mailing list forwarders. I see
lots of paragraphs that begin with "From" that have been decorated to
">From" even though no mbox storage has occurred along the way.
Heavy sigh.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-08-09 12:59:37 UTC
Reply
Permalink
Raw Message
Post by zMan
Before blaming L-Soft, it probably makes sense to be sure the list is
running current software. I know many lists are way backlevel...
The logo at the top of this page shows "LISTSERV 16.0". The page at
http://www.lsoft.com/products/listserv_os.asp shows nothing newer.

And your email headers show:
Received: by LISTSERV.UA.EDU (LISTSERV-TCP/IP release 16.0) with spool id 2528
for IBM-***@LISTSERV.UA.EDU; Wed, 9 Aug 2017 07:30:08 -0500

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2017-08-09 13:01:16 UTC
Reply
Permalink
Raw Message
OK, fair 'nuff! I'm on a horrible connection, wasn't inclined to dig.
Has anyone asked them? Just wondering. They at least used to be a great
company.

On Wed, Aug 9, 2017 at 9:00 AM, Paul Gilmartin <
Post by Paul Gilmartin
Post by zMan
Before blaming L-Soft, it probably makes sense to be sure the list is
running current software. I know many lists are way backlevel...
The logo at the top of this page shows "LISTSERV 16.0". The page at
http://www.lsoft.com/products/listserv_os.asp shows nothing newer.
Received: by LISTSERV.UA.EDU (LISTSERV-TCP/IP release 16.0) with spool id 2528
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
zMan -- "I've got a mainframe and I'm not afraid to use it"

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-08-09 13:13:05 UTC
Reply
Permalink
Raw Message
Post by zMan
OK, fair 'nuff! I'm on a horrible connection, wasn't inclined to dig.
Has anyone asked them? Just wondering. They at least used to be a great
company.
They won't talk to me, or even let me subscribe to their own LISTSERV unless
I have a customer ID. Is Eric Thomas still in charge? The list at
http://www.lsoft.com/corporate/ericthomas.asp#3 seems to show he's been
quiescent for a decade.
Post by zMan
Post by Paul Gilmartin
The logo at the top of this page shows "LISTSERV 16.0". The page at
http://www.lsoft.com/products/listserv_os.asp shows nothing newer.
Received: by LISTSERV.UA.EDU (LISTSERV-TCP/IP release 16.0) with spool id
2528
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Smith III, Phil , HPE Data Security Voltage
2017-08-09 14:46:27 UTC
Reply
Permalink
Raw Message
Gil,

Contact me off-list if you haven't heard from me already (I have an email address for you but it may be old).


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...