>>>>
>>> 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.
<
http://www.courier-mta.org/draft-varshavchik-exdata-smtpext.txt>
That suggests the server should return "EXDATA" in its EHLO reply. Then the
client can use "EXDATA" as an argument to MAIL. After that, special reply
codes are used after DATA. They're not LMTP reply codes, but can easily be
parsed to yield LMTP reply codes. So that shouldn't be a deal breaker,
although it is something of a disappointment.
What I had in mind was a new SMTP verb which would switch the entire
session (all subsequent MAIL commands) into LMTP, but I like the MAIL
argument better. I just wish that it was a switch into LMTP, and not
something almost, but not quite the same.
Anyway, Courier-MTA does seem to support this as both SMTP client and
server.
>
> 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.
True. So it might be fairly simple to support EXDATA as a client, given
that Exim already has an SMTP transport. And, given that SMTP, LMTP and
EXDATA are all pretty similar, it shouldn't be too hard to get the
framework for EXDATA server support in place. Perhaps the DATA ACLs will
require some extra work.
Here, Tony Finch says "this is of dubious utility if the spammers don't
also use it...". <
http://fanf.livejournal.com/51156.html>.
Perhaps, but it does at least allow us to handle non-spam, or even
forwarded spam, in a better way. And, don't forget that some spam might
actually be sent through well configured servers.
> 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.
Anyone have a feel for Courier's market share? Exim seems to have had at
least 8% in 2006. It's probably higher in HE, which makes this valuable for
me even if Exim were the only platform enabling it. Courier's default
greeting seems to be "ESMTP <hostname>", so it must make up a portion of
the 50% or so of SMTP servers that don't identify their software in the
greeting.
>
> 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
--
Ian Eiloart
IT Services, University of Sussex
x3148
