On Mon, Oct 27, 2003 at 11:07:36PM +0530, Madan Ganesh Velayudham wrote:
Hi,
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,
MG
**************************
Madan Ganesh Velayudham
madan-ganesh(_dot_)v(_at_)hp(_dot_)com
+91-80-205-3108
**************************
+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.
250-INVITE
If neighbour SMTP server does not recognize the INVITE command, it
would return 5xx return code. The sending SMTP server can ignore the
reply.
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
Hewlett-Packard
madan-ganesh(_dot_)v(_at_)hp(_dot_)com
--
/Matti Aarnio <mea(_at_)nic(_dot_)funet(_dot_)fi>