Re: [exim-dev] Extended SMTP DATA Reply

On Fri, Nov 17, 2006 at 12:47:23PM -0500, Wakko Warner wrote:
>
> Sounds like LMTP to me. Which I don't see why LMTP isn't used for this, the
> only difference that I recall is the fact that instead of EHLO/HELO, it does
> LHLO and at the post data phase, it gives a code for each recipient. Other
> than that, it seems like it is just ESMTP. I'm not sure about extensions
> such as pipelining, auth, etc with LMTP.

Well, RFC 2033 specifically states that it MUST NOT be used on port 25.
And if it were, it would break normal SMTP mail transfer since an LMTP
server doesn't understand HELO/EHLO. While you could make a combined
SMTP_LMTP server that would change behavior depending on HELO/EHLO or
LHLO, it would probably be better all around to just make the behavior
an ESMTP extension.

As for the original proposal, I don't particularly care for it. My
reasons:
* Why the all-or-none restriction on using EXDATA for individual
messages in a session?
* Instead of the weird embedding of the data in a 558 response, why not
just make the behavior exactly like LMTP? It's not like any sort of
compatibility with old clients must be maintained since old clients
should never have specified EXDATA in the MAIL command.
* If it keeps the 558 reply, it should specify what is to be done if a
*malformed* 558 reply is given.
* The draft should specify as RFC 2033 does that there is to be exactly
one response to each successful RCPT command, even if multiple RCPTs
end up specifying the same forward-path.
* The draft should probably mention the RFC 3030 (formerly 1830)
CHUNKING extension, and probably mention the intended interaction
with anything similar that extends/replaces DATA.
* I would make it more clear that the server should flush subreplies
to the client as soon as they are generated, instead of buffering
them.
* As far as one recipient taking too long and impeding all subsequent
recipients' deliveries, I would suggest the client SHOULD shuffle the
remaining RCPT commands on the next delivery attempt, at least by
putting the first "failed" recipient at the end of the list.

While the extension would seem to be interesting and useful, it's not
likely to actually affect much spam since spammers can just not use the
extension if they find it detrimental. Maybe that's why the all-or-none
restriction, to keep them from trying both ways without reconnecting.

If I were to try implementing something like this in Exim... I'd
probably add a new acl 'acl_smtp_exdata' (would we want
'acl_smtp_exmime' too?). If acl_smtp_data or acl_smtp_mime denies or
drops, report the denial for each recipient (or maybe '550 Ditto' for
subsequent recipients). Otherwise, call acl_smtp_exdata per-recipient.
Probably make drop equivalent to deny in acl_smtp_exdata. Per-recipient
acl variables might be useful, although they could easily enough be
faked using a counter and ${extract on a normal variable. Definition of
acl_smtp_exdata would cause the extension to be advertised in EHLO.