Stephan,
On Fri, 10 May 2013, Stephan Bosch wrote:
> On 5/10/2013 12:12 PM, Christian Rohmann wrote:
> > Hey Stephan,
> >
> > On 05/09/2013 11:23 PM, Stephan Bosch wrote:
> >> It basically acts as a front-end to your normal MTA. First of all, it
> >> provides a convenient way to add SMTP AUTH support to any MTA. But the
> >> main goal for this project is to implement an SMTP submission server
> >> with full support for the LEMONADE profile
> >> (https://tools.ietf.org/html/rfc4550). It acts as a proxy server, so it
> >> doesn't queue anything; once the client sees a success reply for the
> >> message submission, it is already accepted in the actual MTA queue.
> >
> > I have one remark and one question:
> >
> > Remark: Don't forget XCLIENT / XFORWARD support to help the "real" MTA
> > understand who it's really talking to.
>
> XCLIENT is already implemented. But, afaik, this is only supported by
> Postfix.
Exim has the "-bs" command line option. From spec:
-bs
This option causes Exim to accept one or more messages by reading SMTP
commands on the standard input, and producing SMTP replies on the standard
output. SMTP policy controls, as defined in ACLs (see chapter 42) are
applied. Some user agents use this interface as a way of passing
locally-generated messages to the MTA.
In this usage, if the caller of Exim is trusted, or untrusted_set_sender is
set, the senders of messages are taken from the SMTP MAIL commands.
Otherwise the content of these commands is ignored and the sender is set up
as the calling user. Unqualified addresses are automatically qualified
using qualify_domain and qualify_recipient, as appropriate, unless the -bnq
option is used.
The -bs option is also used to run Exim from inetd, as an alternative to
using a listening daemon. Exim can distinguish the two cases by checking
whether the standard input is a TCP/IP socket. When Exim is called from
inetd, the source of the mail is assumed to be remote, and the comments
above concerning senders and qualification do not apply. In this situation,
Exim behaves in exactly the same way as it does when receiving a message
via the listening daemon.
Could you implement this interface to a backend server, too?
Thanks for your work, regards,
Lutz
