Re: [Pan-users] Sending attachments

[Duncan]

Camaleón posted on Fri, 16 Oct 2015 14:33:47 +0000 as excerpted:

> On Fri, 16 Oct 2015 10:47:47 +0000, Duncan wrote:
> 
>> Camaleón posted on Thu, 15 Oct 2015 17:40:26 +0000 as excerpted:
> 
>>> Any advice about the right way for sending attachments (plain text
>>> and/or binary files) with Pan?
>>> 
> Hi Duncan, thanks for replying and the long explanation. I'll cut the
> text not because is not relevant nor interesting but in the aim to go to
> the main issue.

Appropriate and expected, with posts like mine. =:^)

>> Those aren't corrupted files, as pan sends them anyway.
> 
> Well, the fact a file is sent over the wires does not mean it arrives
> intact, it can get corrupted in transit.
> 
>> They're simply encoded using yenc,
> 
> Oh, that explains all. I've never heard of it before.
> 
>> which was designed as a much more efficient encoder of binary files
> 
> (...)
> 
> And some problems, too:
> 
> https://en.wikipedia.org/wiki/YEnc

Indeed.  But it works very well for news attachments and is /much/ more 
efficient than the usual encoding formats, and pan is a news client, 
so... it's an encoding appropriate to what pan does. =:^)

>> As a result, while the attachment was transmitted y-encoded (aka yenc),
>> and very likely the attachment actually arrived uncorrupted in most
>> mailboxes
> 
> (...)
> 
> People complained about the file was corrupted so I guess this is not
> the case.

I'd put money on it actually being uncorrupted a good 90% of the time or 
more, but as they aren't using a yenc-compatible client, it'll LOOK 
corrupted.  And if they've never done news before, as is likely the case 
as well, the chances of them actually knowing about yenc are miniscule 
(as even people who know about news often don't know about it, unless 
they're regulars in the binary groups, where most regulars will know 
about it, witness your case, obviously knowing about news but not knowing 
about yenc until now), so if it appears to be corrupt, they'll call it 
corrupt, simply because they know no different.

>> OK, be that as it may, what to actually /do/ about it?  How to send
>> attachments that those using traditional mail clients, etc, can read?
>> 
>> Basically, since pan only does yenc attachments, you can't use pan's
>> attachment mechanism when sending to what is actually a mailing list,
>> just gatewayed thru gmane, etc.  There are, however, a number of
>> alternatives that work, letting you pick the one that works best for
>> you.
> 
> In fact I was/am using Mutt to send those attachments (which adds an
> extra work from my part) but always wondered what was the [+] icon
> showing in the Pan's toolbar :-)

OK, so you were already doing the "via mail directly, instead of via news 
and gmane" thing, but were doing it manually, instead of letting pan 
launch the mail client compose window for you. =:^)
> 
>> Likely the easiest for many is to remember how pan behaves when you
>> send a reply directly to the author, instead of replying to the
>> "group", and use that.
> 
> You mean clicking "R" [...]

Well, yes, except that pan allows remapping the keyboard shortcuts, and 
I've long since remapped mine and forgotten about the defaults in most 
cases.  I don't use reply-to-author frequently enough to assign it a 
shortcut, so just deleted the shortcut there, freeing it to be assigned 
to something else.  (If indeed it's "r", that's the shortcut I have 
assigned to toggle view, header pane, match only unread articles, 
function.)

If I do need to reply to author, or mail the message to anyone (like the 
list, or whoever else), I either use reply to author from the menu, or 
simply hit the f/followup, and then delete the newsgroup listing and add 
the email addresses I intend to send to.

> replace the "To", add the Gmane newsgroup and remove the original author
> which is a "no-no" on Debian mailing lists (unless someone states
> otherwise). Also, I need to add the attachment which is indeed very time
> consuming.

If removing the original author isn't desired, don't.  Simply add a 
second email address -- the one for the list, comma and space delimited, 
IIRC.  No problem. =:^)

> What I was doing was simply create a new message from my e-mail client
> (Mutt) and use that. The only drawback I see here is that I need to fake
> the "In-Reply-To" header field in order to get the message threaded
> properly. I'm afraid I will have to keep it that way.

If you have pan setup correctly with mutt as your email client 
(presumably you'd have to invoke a terminal client, running mutt in it, 
since mutt isn't an X-based app), no need to fake anything, as pan will 
open up (a terminal window with) mutt's compose window setup, as soon as 
you put anything in pan's mailto line.  You can actually put /anything/ 
(say a simple xx) on that line and pan will notice it when you hit send 
and trigger the email client compose window, filling in the in-reply-to 
headers, etc, as appropriate, it doesn't have to actually be an email 
address.  However, if it /is/ an email address, you won't have to tweak 
that part in the mail client as it'll already be there.

>> uuenview can actually encode in yenc, base64, or uue.  UUE, the -u
>> option, is what we want, for the reasons explained above.
>> 
>> uuenview -u file
> 
> (...)
> 
> I cannot risk the file or message body is not properly encoded or has
> any problem by using an encoding tool. This can be acceptable for
> sending an image as attachment but nor for a list of translators that
> need to review the file easily. Also, there is Gmane and then the
> mailing list so encoding errors are more prone to come up that for a
> true nntp newsgroup.

Actually, the chances of a bug in the encoding with a purpose-specific 
encoder like uuenview are arguably lower than they are for builtin 
attachment functionality, because builtin attachment functionality is 
just one trivial function in a much larger client, and a bug may not be 
noticed right away, while with a purpose-specific encoder like uuenview, 
encoding is the /primary/ functionality, and if it doesn't work, the 
entire app is broken, so a bug is *much* more likely to be noticed and 
fixed before a release is actually done, than it is in the general 
purpose client that simply happens to have attachment functionality as 
well.

And at least UUE type encoding... as long as the output is separated from 
the rest of the message, should work fine, because that's the way it was /
designed/ to work, allowing a binary file to be text-encoded and thus 
sent as-text, all those decades ago when the Internet was very young.

(Actually, technically, UUE is short for Unix-to-Unix encoding.  It was 
literally designed to let people encode and attach binary files to 
otherwise text-only messages, creatively working around the text-only 
limitation, so these binary files could be sent between Unix machines in 
the guise of text-only messages, back when users were using dumb 
terminals connected up to the multi-user Unix-based computer, generally 
owned and run by their large university or company, back when the 
machines cost tens of thousands of dollars.)

>> Once your tests are working, /then/ send your first real manual
>> attachment to the list. =:^)
> 
> I'm afraid I give up O:-)

Which is why I automated the process, with a nice, friendly GUI as 
provided by kdialog, using my pan-attach-kd script.

Keep in mind that this was before pan had any attachment ability at all, 
long before it allowed yenc-based file attachments.  Literally the /only/ 
way to attach files to pan messages was to use a separate encoding tool, 
and paste them directly into the body.  I simply automated the process.

> That's really nice, but I expect this task is completely done by the
> newsreader (I mean, no more extra work from my part).

Well, it is, when the readers are newsgroup readers, as could be expected 
for a news client creating a reply and attaching files.  In that case, 
yenc-based attachments are the most efficient method, and are thus 
generally strongly preferred to other methods, which will require much 
larger messages to hold the attachments, due to the much worse encoding 
efficiency of other common encoding algorithms, including those normally 
used for email as well as news.


> Anyway, have you thought about adding/embedding those utilities into
> Pan?

Have you?  If you were to code up the patch allowing the user the choice 
of encoding type, I have little doubt it'd be accepted.

I'm not a dev, and thus can't do so myself (probably the reason you don't/
can't as well).  I'm simply a very long time (well over a decade) user of 
pan and regular on this list, with enough admin skills to know bash 
scripting reasonably well.  So I used the tools at my disposal, bash 
scripted kdialogs and otherwise command-line-based encoding tools, to 
automate a task that was otherwise entirely manual, hooking it into pan's 
GUI by the only method really exposed to do so, as an "external editor".

It's a pretty clever workaround for the problem at hand, given the 
limitations I had to work within, if I do say so myself.  Remember, this 
was before pan had builtin file attachment posting of any sort, so the 
other alternative was entirely manual, and I automated the process using 
a GUI, in the only way that I could.

If I knew C++, I'd have certainly added the functionality directly to 
pan, but I don't, so I did what I could with what I had available, and I 
really do believe I did a pretty good job, given the limitations I was 
working within.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman