Pat file attachments do not forward?

[Wiley Sanders]

I am doing some research into using Winlink/Pat in peer to peer mode on an AREDN network. My scenario involves accumulating messages at a P2P node that might be operating at a location where both AREDN and internet connectivity are available. The P2P host would normally not be configured to route TCPIP between the internet and AREDN. So, to jump the "air gap" between internet and AREDN, message forwarding is needed. 

Because the embedded forms used by Winlink use the B2F format, embedded forms are only decipherable by other Winlink clients. I was hoping to overcome this by specifying that the originating form not be in embedded form format but be attached as a PDF file. This works fine between winlink clients (like pat).

What I have found is that when "forwarding" a message (to cms.winlink.org) using pat, the attachment is not included when composing the message. My question is: Is this a bug in pat, or is this the way Winlink forwarding is supposed to work? 

It's worthwhile to note that winlink.org reject messages over 120k in size anyway. 

It's possible to script something using "pat extract" and send the mail via smtp/binmail or some other API. I'm OK with this if that's the way it's supposed to work.

Other approaches to linking AREDN Winlink to the internet are possible, but this is the one I am testing for the moment. We have a few CMS gateways up on the mesh in the SF Bay area, but they are undocumented hacks (in a positive way!) for the time being. 

Off topic, but IMHO what way Winlink handles forms is a disaster. Eventually, form handling should have been split off ages ago and managed as separate application from the core Winlink protocol. But the embedded text+XML is the world we live in now.

Wiley KF6IIU

[Martin Hebnes Pedersen]

Hi Wiley,

Regarding the attachment not being included when forwarding the message: This is unfortunately a TODO: https://github.com/la5nta/pat/issues/102

For now you’ll have to save the attachment to disk and manually add it to the forwarded message.

I hope we can get this implemented soon, as I can imagine the frustration when discovering this missing feature.

— 

73 de LA5NTA / Martin

--
You received this message because you are subscribed to the Google Groups "pat-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pat-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/pat-users/24514922-84e2-4b58-90cc-dd42d9cb9db7n%40googlegroups.com.

[Wiley Sanders]

Thanks Martin for the quick reply,

I don't find it frustrating at all! As a matter of fact, it's not a high priority for my situation, because any attachment forwarded to a non-Winlink client would need to be translated from B2F to standard email MIME format before it could be forwarded via, say, the Google email API. Even if the message were forwarded to another Winlink CMS/RMS, the CMS/RMS node would have to translate the attachment to MIME if the destination was other than Winlink (cms.winlink.org does not include B2F attachments either.)

So, not a big priority for me. I'll see if I can fashion a workflow for this using "pat extract" and the Google API for this going forward. I'll post back on progress.

BFF/B2F attachments must have been designed back before MIME attachments were standard. No reason to have a proprietary format now, it doesn't save any space. Or maybe there are some packet protocols that can't handle compressed or non-ASCII data.

Wiley KF6IIU