Subject: RE: SMTP Use Cases

From: "Martin Stecher" <[email-masked]>
Date: Mon, 15 Nov 2004 14:27:01 +0100

jfc,

> 
> 1. resuming interrupted sending. Probably several cases and ways.

I understand that this could be:
  An MTA sends a message to another MTA. Due to network problems
  the connection aborts while sending the email in the DATA command.
  "Resuming the interrupted sending" will allow to start a second
  attempt and only send the part of the message that the receiver
  didn't get in the first run?

To me this seems to require additional commands in the SMTP dialog.
Should we propose OPES use cases for SMTP additions that are not
yet defined? I think we should do better without those.

> 2. virtual transfers. When the same mail is sent to several 
> recipients, the 
> first copy could be transfered with meta data defining the others to 
> rebuild on the arriving MTA.

Agree with Tony. This is is already part of SMTP (multiple "rcpt to").

> 3. compression during transfer
> 

If this should be something like a Transfer-Encoding, it is outside
of OPES. If you think about a content encoding for compression, it is
another example of case 1-6 "Format Conversion".
Do you agree?

Regards
Martin

---

From: jfcm <[email-masked]>
Date: Mon, 15 Nov 2004 15:24:13 +0100

At 14:27 15/11/2004, Martin Stecher wrote:

>   attempt and only send the part of the message that the recno

Martin,
the interest of OPES/SMTP is that it can provide services on top of SMTP 
without changing SMPT (or this would not be an OPES whatever this may mean) 
but an ESMTP additional feature.

The use as I see for example for South Pacific Islands, ships, space craft, 
mobiles etc. one OPESMTP filter on each end of the link and two servers. 
They notes the headers and forget them once the transfer is completed. When 
an uncompleted mail is resent the sending side OPES sends a message to the 
OPES on the receiving end to reinject the part it already has.

This same mechanism could also be used to send a multiple copy mail only once.
>Agree with Tony. This is is already part of SMTP (multiple "rcpt to").

I am not sure as I am not SMTP header. But I do not think so as this is not 
UA or MTA related but bandwidth management related. The group of SMTP hosts 
to be supported (filtered) should be reported to the OPES system.

>another example of case 1-6 "Format Conversion".

Again, I am not versed enough in SMTPing to fully understand the question. 
Better I give and example and take back the SoPac case. The point is to 
enhance the satellite link usage or provide delayed delivery in case of 
temporary failures. Compression may be considered only between the sending 
and receiving ends. This is just on a network segment. This could be used 
for many other applications, but SMTP is a much demanded one with its own 
specifics. Example: right now on the main list is discussed the case of 10 
M Yahoo attachments with a usual limit of 2 M. The transfer of a large 
attachment could be negotiated vs compression, delayed transfer at off-peak 
hours, routing through another link, delivery to another equivalent mail 
box (using for example a low priority MX address, etc.)

I fully agree that we do not want to propose changes to SMTP (all the more 
than I consider SMTP being overloaded as the reason of spam). I am not 
against enhancing SMTP in "polluting" the SMTP demands with good OPES 
solutions, SMTP designers could decide to include in their specs. But we 
should adopt the position that SMTP is used in application as an 
asynchronous signaling protocol with very limited features being used, to 
trigger different services that could be loaded as private OPES. So the 
least we are involved with SMTP advanced features probably the best?
jfc