Apologies for a not-entirely-Exim-related question; I have spent time on
this list in the past, and I know that the people who read it know a
hell of a lot about Internet email. Just hoping I can bounce this loopy
idea off of you and see what comes back.
Anyways: I work for a company whose main product is a suite of server
applications deployed at medical clinics and hospitals worldwide. Each
of these deployments is a cluster of servers with rather tenuous
connections to the public Internet. However, we still want the ability
to send email from those servers to arbitrary addresses. Here's one
scenario: Dr. John Smith has an account in our user database with email
address john.smith@???; we need to send him an email when his
account is about to expire.
The obvious answer is to setup an MTA at each customer site that's
configured to relay through the customer's outgoing SMTP server. If
that was feasible, though, I'd just walk down the hall, haggle for a few
minutes over Exim vs. postfix, and get on with it.
Unfortunately, our customers present a variety of reasons why we cannot
use SMTP for outgoing email. Maybe one won't open port 25 to our
servers, another insists outgoing email must be virus-scanned, and
another just gives us a blank stare when we ask what the SMTP relay host
is.
The one ray of hope is that we already have guaranteed HTTPS
connectivity from customer sites to a support server on our premises.
(We can't monitor the remote deployments without it, so opening outgoing
port 443 to this one special host is pretty much a prerequisite for
being one of our customers.)
So ... why not tunnel SMTP through HTTP? IOW, when we *want* to do
this:
<connect to mail.example.com:25>
MAIL FROM:<admin@???>
RCPT TO:<john.smith@???>
DATA
Subject: Your account is about to expire
Date: ...
Content-type: ...
Dear Dr. Smith: your account is going to expire next Wednesday.
blah blah blah blah blah
.
<close connection>
then we would *actually* do something like this:
<connect to our central support server:443>
POST /smtpgateway?sender=admin@???&recip=john.smith@??? HTTP/1.1
Content-type: application/rfc822
Subject: Your account is about to expire
Date: ...
Content-type: ...
Dear Dr. Smith: your account is going to expire next Wednesday.
blah blah blah blah blah
<close connection>
Something running on the central support server would translate that
HTTP request into an SMTP conversation with its local MTA. (Or just
open a pipe to /usr/sbin/sendmail: whatever.) It would be really nice
if this was transparent to applications: that is, an application running
at a customer site that wants to send email would just open a pipe to
/usr/sbin/sendmail -f admin@??? john.smith@???
and write the message down that pipe. The local MTA would then take
care of queuing the message and *sending it out over HTTP* instead of
SMTP.
(There are, of course, any number of ways to translate an SMTP
conversation into an HTTP request. I propose putting the envelope into
the URI and the message headers + body into the HTTP request body. The
details are secondary; you get the idea.)
My questions are:
* surely I'm not the first to think of this. (I didn't find very much
Google'ing for "smtp http gateway" or "smtp http tunnel".) Either
there's an existing solution out there, or it is generally
considered a dumb idea. Anyone know which it is?
* if there is an existing solution out there, is there one that works
with Exim? I think this would require a special router, which would
mean hacking Exim.
* if there is an existing solution out there, is there one that works
with postfix? I'm quite familiar with Exim, but curious about
postfix and not terribly religious about choice of MTA. (As long as
it's open source, maintained, and doesn't suck, which AFAIK narrows
the field down to Exim and postfix.)
* of course, the other half of an "existing solution" is an HTTP
service that receives those SMTP-wrapped-in-HTTP requests and turns
them back into SMTP. That should be MTA-independent, of course, but
it would be nice if the code already exists.
Thanks in advance!
Greg
