Subject: Re: [Asrg] MTP draft

From: "Jacqui Caren" <[email-masked]>
Date: Tue, 04 Mar 2003 16:41:03

On Tue, 4 Mar 2003 17:02:29 +0100, Hadmut Danisch wrote:

> Hi,
> 
> it was already mentioned that a redesign of the Transfer
> Protocol might be taken into consideration. I was already
> collecting some thoughts when this working group came up.
> 
> Due to the forthcoming IETF meeting, it is currently not
> possible to submit drafts. But if anyone likes to have
> a glance at it:
> 
> http://www.danisch.de/tmp/draft_mtp.txt

My first thought - how about RSET or equivalent?
This is used far more often than may be thought to
clear down a SMTP connection to sync states of
originating and recipeint MTA's.

I am doinw some work for a client that is delivering
content to customers via email (subscription service!)
and we are hitting the limits of sendmail - RSET is a
godsend when SMTP gets in a tizzy and you just want
to wipe the slate and resubmit.

Jacqui Caren, Ingram Group Ltd. [email-masked]
ph: +44 (0) 1483 8628xx main=00 fax=01 ddi=65
http://www.ig.co.uk/ http://www.sitedirector.org/
http://www.perl.co.uk/

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 4 Mar 2003 18:09:23 +0100

> originating and recipeint MTA's.

A MESSAGE command should always start from scratch
and implicitely include a RESET.

As an exception, the TLS state might remain unchanged until
a new STARTTLS command was issued.

And maybe successful authentications (SASL...) could stay
alive and collected till the end of the connections. But since
this is a matter of extensions it is not to be defined in the 
protocol itself. 

But I'll keep that in mind and think about it...

regards
Hadmut

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 4 Mar 2003 12:13:09 -0500 (EST)

> http://www.danisch.de/tmp/draft_mtp.txt

One shortcoming of SMTP that really needs fixing is this: When you
send e-mail to multiple recipients, it is not possible to indicate
successful delivery to some recipients, but not all recipients, after
the data phase.

Therefore, rather than just a numeric reply code, I think the protocol should
reply with headers of its own.  For example, if the client says:

	Deliver-To: <[email-masked]>
	Deliver-To: <[email-masked]>

then the server should be able to reply:

	Delivery-Status: <[email-masked]> 200 Accepted
	Delivery-Status: <[email-masked]> 554 Unacceptable content

Perhaps (probably) you intended this, but let's make it explicit.

--
David.