On Tue, Jan 25, 2011 at 8:23 AM, Ian Eiloart <[email protected]> wrote: > --On 20 January 2011 22:07:33 -0800 Claus Assmann <[email protected]> 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
