Re: [dtn] draft-blanchet-dtn-email-over-bp-00.txt

["Stuart W. Card" <[e-mail]>]

Marc et al --

Yes please, pursue email/BP!

I am a big fan of these 3 related but distinct things:

- email encapsulation over BP;
- BP encapsulation over email;
- email <-> BP translational gateways.

Before BP, we developed a mostly transparent gateway that provided DTN 
services to legacy applications for the U.S. Navy submarine force.

I tried to summarize that work in a post 2004 JAN 22 to what was then 
the DTN Research Group mailing list, with subject line
'lurker describes related work (was: DTN "Community Rapporteurs"?)',
which can be found in the archive at
https://mailarchive.ietf.org/arch/browse/dtn-interest/
I am amused to see that the day after tomorrow, it will have been 
exactly 19 years since I posted that. ;-/
Attached are 2 papers we presented at MILCOM later in 2004 and a 
PowerPoint presentation from 2003 when we were still working on 
automatic rule-based prioritization of traffic (I will have to ask our 
marketing guy to look for a block diagram of its final configuration).

Our [non-real-time web browsing proxy over] email stack on the SATCOM 
segment was something like this (from my hazy memory):

[HTTP]
PBS
BSMTP
bzip2
GnuPG
MDPv2
UDP
IPv4 multicast

I can't find GnuPG/OpenPGP in the block diagram but am sure it was there 
(eventually, in some version), between compression and bundle transport.

Of course, later we replaced the Naval Research Lab (NRL) Multicast 
Dissemination Protocol (MDPv2) with the NACK Oriented Reliable Multicast 
(NORM) transport protocol, which I believe remains the _only_ IETF 
standards track reliable multicast transport protocol that uses Type II 
hybrid ARQ/FEC to efficiently provide reliable delivery by adapting to 
widely dynamically varying error rates on network paths. Last I knew, 
somebody had a BP convergence layer for NORM, and I have long owed the 
DTN WG a draft on it. :-/

We used stack variants for different traffic types, e.g. SCPS-TP for TCP 
connections of applications for which we lacked an app layer proxy.

PBS was the Portable Batch System. This was an "active network" where 
each bundle we transported contained a shell script that invoked the 
necessary service on the DTN destination Internet to do the appropriate 
thing for the encapsulated payload type.

The ability of Postfix to deliver mail to a process was a big help. We 
just hand-whacked the Postfix transport database to use our homegrown 
DTN stack for specific domains that we knew were on the other end of the 
SATCOM segment.

BSMTP (Batch SMTP) enabled us to use actual SMTP (then RFC2821) envelope 
information ("MAIL FROM" and "RCPT TO") rather than Internet Message 
Format (IMF, then RFC 2822) content header information. Inferring the 
former from the latter has long been known to be dangerous, so please 
look at some of what has been written on that subject before deciding. 
Sadly I can't remember any specific references but do remember reading 
about mail routing loops and other problems.

Sorry for the huge and poorly referenced data dump. Also, to be clear, I 
am not trying to claim priority or anything like that, just trying to 
provide some potentially helpful information based on our experience. 
Happy to chat if you like. Now back to nominally paying work...

On 1/17/2023 7:32 PM, Marc Blanchet wrote:
> 
>> Le 17 janv. 2023 à 19:14, Jorge Amodio <[e-mail]> a écrit :
>>
>> Why not BSMTP using CFDP ?
> 
> I looked at that too... Having a raw RFC822 payload is as simple as it can be. I like things simple...

-- 
Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[e-mail]> www.critical.com