On Tue, Jan 30, 2007, Eric A. Hall wrote:
I would imagine that ietf-smtp(_at_)imc(_dot_)org is the right place to talk
If the current participants of this thread agree, we can move the
discussion over there.
deferred-rcpt-responses would be most descriptive but that's a bit greedy
given that command-line space is fixed. I don't really care what people
call it. Robots will be the 99.9999% use case and they won't care either.
Probably some kind of acronym like DRR or whatever would be most efficient
as far as that goes.
"DRR" is fine, currently I call it "RSAD" in my implementation, but
that's trivial to change.
I changed the section 6 heading in the current draft. The additional
breakdown looks reasonable and appropriate so I'll do that in the next
edition if there's any real interest in pursuing this further.
I'm interested. I'm currently implementing it in my MTA, and I can
implement it in the (still?) most widely used MTA if we get this
to an RFC.
Please make also the change to require PIPELINING, as LMTP does:
5. Implementation requirements
A server implementation MUST implement the PIPELINING [PIPELINING]
and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions.
Asrg mailing list