Chambers, Phil wrote:
>
>> -----Original Message----- From: exim-users-bounces@???
>> [mailto:exim-users-bounces@exim.org] On Behalf Of Ian Eiloart Sent:
>> Mon 06 October 2008 12:01 To: W B Hacker; exim users Subject: Re:
>> [exim] RFC 5321, 5322
>>
>>
>>
>> --On 4 October 2008 05:12:18 +0800 W B Hacker <wbh@???>
>> wrote:
>>
>>
>>> - Too few long-standing needs have been addressed. It is
>> close to ten
>>> years since Courier-MTA introduced a post-data phase extension
>>> that would allow a server to say WTTEF: "10 of those 13 will
>>> accept that these 3 will not." Ability to check content and
>>> return a
>> modified list
>>> of accept/reject while still 'online' is essential - and
>> much 'cheaper'
>>> than playing with potentially damaging after-the-fact 'bounces'.
>>>
>> I propose an SMTP extension, allowing two hosts to switch into
>> LMTP, which does permit this. The LMTP protocol is nicely defined,
>> and lots of code exists.
>>
>> Am I right in thinking that, if such an extension existed, it would
>> be relatively easy to modify Exim to support it?
>>
>>
>> -- Ian Eiloart
>
> Exim currently supports sending using LMTP (that is how I have it
> configured to submit into our old Cyrus maystore).
>
> I am not in a position to say how much effort it would be to receive
> on LMTP. Clearly it would need new functionaliy for ACLs to manage
> post-data rejections.
Adding that functionality - with or without (re)use of LMTP code, is not
hard. One could, if only for experimentation, even discard the entire
router-transport section and perform the same functionality in acl's
(easily done with SQL calls if not scripts).
BUT - that is not the barrier!
The barrier is that no other MTA *expects* to work to that sort of
additional handshake after the DATA phase.
Except courier-MTA with EXDATA.
So it isn't 'enough' to modify only Exim and support Exim <=> Exim
transfers. That's the same isolation as courier-mta has had lo these
many years.
One either has to (first) try to implement workability WITH courier-MTA
as an easily tested first step, since the functionality is already
there, and documented - OR dig out Sam's original draft RFC proposal,
run it by Postfix and Sendmail teams, (again), and see if some sort of
updated compromise can be agreed - at least for R&D testing.
NB: Sam's was not the only such solution ever postulated. But AFAIK, his
is the only one that made it into actual code and has been shipping for
a long time. That has value. Bigtime.
Best to finalize an RFC extension only AFTER some proof that more than
one of the disparate MTA can manage to communicate with 'foreigners',
not just siblings.
Exim's source is in C and GPL'ed
Courier-mta is partly C, and partly C++, but also GPL'ed.
I'd rather take a bullet than code in C, but I can put a pair of
machines into testbed use.
I don't know how the Exim community feels about basing this sort of
extension on what courier has already demonstrated, but I have reason to
believe Sam would not be averse to seeing others try to build on it.
Thereafter, the F/OSS way is to argue like Hell over changes and
improvements, but THAT's a road well-enough traveled...
;-)
>
> I would be VERY keen to see developments along these lines. It is
> clearly the best way to manage per recipient options on
> spam-scanning.
>
http://www.courier-mta.org/draft-varshavchik-exdata-smtpext.txt
There are others, but, as said, this one was implemented.
Bill
> Phil. -------------------- Phil Chambers Postmaster University of
> Exeter
>
