Batching mail

[John Plate <pl...@infotek.dk>]

Hi

I need a mail system that makes it possible to batch mail and send it
as a single, compressed file. On the other end it should be possible
to uncompress the mail batch and inject the mail to the mail server
for delivery. 

In that way it should be possible to use any pop3-capable MUA to read
and write mail. The transport will be the only "special" thing.  

In good old days, uucp used bsmtp to do the same thing. This is mostly
Unix-only. The good thing with James it that it is platform
independent and may run on most systems.

One use of this system is when dial up cost is heavy. Fx. a wessel
navigating on open sea could have a sattelite phone and make one daily
call to exchange mail. The phone cost is high, so sending one big
compressed batch of mail is very attractive.

I would like to know if someone has already made something like this -
or has some suggestions and/or ideas.

Thanks in advance
-- 
John Plate 

---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org

RE: Batching mail

[Danny Angus <da...@apache.org>]

John,

In may ways James would be an ideal platform for this beacuse it is designed to be highly customizable and built on top of work from Avalon (http://avalon.apache.org) it is possible to enhance and/or change most of even the fundamental functionality of James. 

What you want contains many more generally usefull features, most of which are not available at the present time. :-(

Batching, and a proprietery optimised james<->james protocol would be valuable enhancements to many classes of user, and I know that sendmail can use its own optimized protocol when it knows that a compliant version of sendmail is on the opther end, so there is a real world example of this.

For your specific needs you could write a mailet which adds all specified mail to a compressed archive, attach that to a normal mail message and then use *any* available SMTP access, not necessarily another James, to route this archive to the break-of-bulk point.

So the internet gateway would write all mail for each remote station to a zip for outbound transport, and the remote stations would each write one for all inbound mail.

You would have to write a de-archiver which would insert de-archived messages into James' spool for their re-introduction into "normal" transport.

I would envisage that mail to ships would be handled by a landbased server bulking-up mail, and archived mail from ships could be transmitted via SMTP to the same gateway for forward transport.

Then transfer would be of single (or few) messages with attached compressed archive of outbound or inbound mail. So we're piggybacking our compressed transport on SMTP.

The second problem contained in your use case is that of timing, mail protocols have no concept of delivery scheduling, which could be the major problem, but I can see some ideas that might help..

a) outbound archived mail is periodically delivered into a local inbox from where it can be picked up by a FetchPOP (of the forthcoming FetchMail) fetch task. But this would have to be scheduled more accurately than is currently possible, even cron timimg may not be accurate enough to really keep connection durations low.

b) Use a hybrid protocol in which servers are assigned roles of remote and gateway, remote stations initiate all traffic when they receive inbound pings from the gateway. This idea allows the remote station to decide if this is an acceptable connection to use for mail, and if so it will make best use by initiating simultaneous upload by SMTP and download by POP3 of archived mail.

At the end of the day the lack of a permanent connection, and how a transient one is managed would govern what you should and shouldn't do.

If charging is by the duration of connection or volume of data alone then simply making James compress mail to be exchanged would be an improvement. 
If there is a minimum connection charge, or if connections have to be pre-booked, or if the connection chanrge varies up or down with the duration of a connection or the quantity of data, then optimizations would have to be much more sophisticated.
Obviously for a connection charged by duration provision for simultaneous up and download would be a significant cost saving, but for volume based charging this saving might not apply.

(Do these ships generate a lot of mail?)

d.

> -----Original Message-----
> From: John Plate [mailto:plate@infotek.dk]
> Sent: 17 March 2003 08:25
> To: James Users List
> Subject: Batching mail
> 
> 
> Hi
> 
> I need a mail system that makes it possible to batch mail and send it
> as a single, compressed file. On the other end it should be possible
> to uncompress the mail batch and inject the mail to the mail server
> for delivery. 
> 
> In that way it should be possible to use any pop3-capable MUA to read
> and write mail. The transport will be the only "special" thing.  
> 
> In good old days, uucp used bsmtp to do the same thing. This is mostly
> Unix-only. The good thing with James it that it is platform
> independent and may run on most systems.
> 
> One use of this system is when dial up cost is heavy. Fx. a wessel
> navigating on open sea could have a sattelite phone and make one daily
> call to exchange mail. The phone cost is high, so sending one big
> compressed batch of mail is very attractive.
> 
> I would like to know if someone has already made something like this -
> or has some suggestions and/or ideas.
> 
> Thanks in advance
> -- 
> John Plate 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org