ietf-openproxy
[Top] [All Lists]

RE: SMTP Use Cases

2004-11-15 08:02:34

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

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 recno
  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.

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.
> 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").


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.

>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?

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

<Prev in Thread] Current Thread [Next in Thread>