On Tue, Jan 25, 2011 at 8:23 AM, Ian Eiloart <iane@???> wrote:
> --On 20 January 2011 22:07:33 -0800 Claus Assmann <exim@???> wrote:
>> I don't need too, I already implemented it in one MTA, and if I
>> had the time, I could put it into another "main stream" MTA.
> Given that Exim has significant market share, I for one would welcome that
> feature. Which MTA is it that implements the feature?
Based on a google search, plus I happen to have seen Claus' name in
sendmail circles, I'd guess sendmail.
http://mail.aegee.org/patches/sm8.14.4-prdr.patch
However, having said this, I note that it is an outside patch, not in
sendmail as an FFR, which kind of suprised me.
> 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?
> would permit better code reuse, and would avoid the need for administrators
> to learn the differences between LMTP and PRDR (PRDR adds a "final response
> code", which seems redundant to me). Otherwise, it's pretty similar.
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. 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).
I started playing with adding PRDR to exim. I am familiarizing myself
with exim code and so far, I've only touched smtp_in.c. Exim's code
path is actually pretty easy to decipher (I anticipated an older code
base like this to be very difficult to read). I've made some simple
code changes that should detect the request, but I don't yet have the
logic to act on it, nor a config option to enable/disable it. I have
neither begun to peruse outbound code or logic, strictly working on
inbound at this point. My code is still very infantile at this point
and doesn't actually do anything yet.
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). In this case, we're
extending an MTA system with queuing to do per recipient responses
similar to LMTP. Exim, along with all queuing MTAs, can already
handle partial rejected envelope recipients destined for different
mail hosts in a single email, so I see no technical difficulties with
having rejection of partial envelope recipients destined for the the
same mail host (it just needs to keep track of it the same way).
However, to use LMTP outside the LAN requires changes to the RFC, and
the PRDR draft does seem to bridge that difference. I would expect a
lot less shouting, finger pointing, and name calling on the IETF lists
than trying to change an existing RFC. And if the goal is getting
something to a point where it can become a candidate with IETF, then I
would go the path of less resistance (less, not least because there's
always resistance there :-)
--
Regards... Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm. -- Marcus Aurealius
