--On 25 January 2011 12:25:50 -0800 Todd Lyons <tlyons@???> wrote:
>
>> An alternative to implementing PRDR would be to use an SMTP verb that
>> changes the session to an LMTP session. I'd use "LMTP" as the verb. That
>
> To be clear, you're proposing to modify the LMTP restriction that it
> must not be used on the SMTP port, and not on WAN networks, right?
Well, I guess that's part of it. But actually the client and server would
have to know that they both supported LMTP. The server could advertise it
in its response to EHLO, and the client could then ask to switch to LMTP.
I'd envisaged using a new verb: "LMTP", but an argument to MAIL FROM would
be an alternative that would mean the client could make use of the facility
on a per-message basis. It would also mean one less round trip in the
session.
> I looked at Eric Hall's draft and was impressed that it was very much
> what I had in my mind when I asked the original question except that
> the draft doesn't need a new verb from the client, just one extra
> value after the MAIL FROM.
Yes, that's nice.
> And the final response code is only
> required if any one of the recipients is getting rejected (otherwise,
> fallback to a single, regular SMTP response, skipping the 353 response
> and per recipient responses).
Oh, yes, that is an advantage.
>
> I do like the concept to "avoid the need for administrators to learn
> the differences between LMTP and PRDR" because not having to learn
> something new makes my job easier. The reason for forbidding LMTP
> outside of the LAN is apparently to prevent duplicates, but the
> thought process at the time apparently was that the sending system
> doesn't have a queue (the main use case of LMTP).
Oh, I thought the purpose was for when the receiving system doesn't have a
queue. LMTP does allow 4xx temporary rejections. I don't know what the
sender is supposed to do if it doesn't have a queue. Our mail system uses
LMTP to do final delivery into Cyrus mailstores - they don't have queues.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see
http://www.sussex.ac.uk/its/help/
