[Top] [All Lists]

Re: Deliver-qmails-ondemand

2003-10-27 11:12:50

On Mon, Oct 27, 2003 at 11:07:36PM +0530, Madan Ganesh Velayudham wrote:

      I could not complete my draft well before the 
      58th IETF deadline. I thought I would send the
      overview and seek your comments.

      Please share your comments on the attached draft.

First and foremost,  how does this differ from ETRN as is
defined in RFC 1985   ?

      Thanks and Regards,

      Madan Ganesh Velayudham
      +HP/STSD/Internet Services
      Bangalore, India

      Everything is possible

              Delivering queued mails on Demand
Overview :

When a mail cannot be sent, the mail is queued for future delivery. In 
most of the mail server, the server periodically dispatches all of its 
mails. After an attempt, the mails will be put back to the queue and 
will be dispatched after the queue timeout period. That is, there is a 
delay in attempting the next delivery attempt.

This could call for an mechanism by which the neighbour SMTP servers 
can invite or inform the mail server that it has come online and ready 
to receive/relay mails.

Solution :

When a SMTP server comes up, it could send an INVITE command to its 
neighbour SMTP servers inviting that they can dispatch mails addressed 
to this SMTP server. 


If neighbour SMTP server does not recognize the INVITE command, it 
would return 5xx return code. The sending SMTP server can ignore the 

The SMTP servers that can understand and allow INVITE command, can 
start dispatching mails addressed to the SMTP server, issued INVITE.

Issues/Security Considerations :

This draft would discuss about identifying neighbour SMTP servers, 
could be through the site's MX records.

This might introduce denial of service or some related issues. The 
draft would analyze all the issues and solutions.

27-Oct-2003                                           Madan Ganesh V

/Matti Aarnio   <mea(_at_)nic(_dot_)funet(_dot_)fi>

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