(This is a repost of my original patch, now that 1.0 is out and the patch is updated against that version)
Background:
I run tmda-ofmipd to process outbound mail from Outlook Express and/or
Mozilla. I run this over SSL.
At present, I believe the recommended way to do SSL is to have stunnel
port-forward from an inbound SSL connection on port X to tmda-ofmipd
running on port Y.
While this works fine, one issue is that tmda-ofmipd doesn't then know the
client's true IP address (since its connection comes from stunnel,
probably on localhost).
The attached patch updates tmda-ofmipd so it can run in a "single-session"
mode, where tcpserver/stunnel accept a single SSL connection direct from
the client, then have tmda-ofmipd process this single connection. This
way, tmda-ofmipd sees the real client IP.
Full details are in the attached patch_notes.txt.
As a note on how to set this up, I have:
/etc/service/tmda-ofmipd-ssl:
=============
#!/bin/sh
exec \
/usr/sbin/softlimit -m 8000000 \
/usr/sbin/tcpserver -v -R -H -l 0 0 8026 \
/usr/local/sbin/stunnel \
/usr/local/etc/stunnel/tmda-ofmipd-ssl/stunnel.conf 2>&1
=============
/usr/local/etc/stunnel/tmda-ofmipd-ssl/stunnel.conf:
=============
exec = /usr/local/etc/stunnel/tmda-ofmipd-ssl/script
execargs = /usr/local/etc/stunnel/tmda-ofmipd-ssl/script
cert = /usr/local/etc/stunnel/tmda-ofmipd-ssl/tmda-ofmipd-ssl-key-and-crt.pem
client = no
foreground = yes
#debug = 7
#output = /var/log/xxx.log
=============
/usr/local/etc/stunnel/tmda-ofmipd-ssl/script:
=============
#!/bin/sh
exec \
/usr/sbin/setuidgid popuser \
/usr/local/tmda/bin/tmda-ofmipd \
-f -R pop3 -S /usr/local/bin/thames-vdir.sh -1
=============
Note that the above works for one of Outlook Express or Mozilla. I forget
which. I have another service setup identically, except for the stunnel
configuration, on two different ports. The other stunnel config is:
/usr/local/etc/stunnel/tmda-ofmipd-starttls/stunnel.conf:
=============
exec = /usr/local/etc/stunnel/tmda-ofmipd-starttls/script
execargs = /usr/local/etc/stunnel/tmda-ofmipd-starttls/script
cert =
/usr/local/etc/stunnel/tmda-ofmipd-starttls/tmda-ofmipd-ssl-key-and-crt.p
em
client = no
foreground = yes
protocol = smtp
#debug = 7
#output = /var/log/xxx.log
=============
The difference is whether the client negotiates SSL directly, then does
SMTP, or whether they start SMTP (i.e. HELO etc.) then issue STARTTLS to
enter SSL mode.
--
Stephen Warren, Software Engineer, Parama Networks, San Jose, CA
[EMAIL PROTECTED] http://www.wwwdotorg.org/
1. Add -1 option to trigger new functionality.
2. Update SMTPChannel.__init__ to read local/remote socket information
(ip/port etc.) from environment variables set by tcpserver if they
are present.
Note that the code always uses those variables if they're present.
Perhaps you want to replace:
if os.environ.has_key('TCPLOCALIP'):
with:
if one_session:
so that everything is 100% backwards compatible to reduce risk.
The new code is a tiny bit more exhaustive in retrieving all
information about the local and remote endpoints, for completeness.
References to localip replaced with cached self._localip set by new code.
Also removed addr parameter - it was simply stored as a member variable
and wasn't used.
3. Reworked class hierarchy of SMTP server classes. There are now:
SMTPChannel
As before
MessageProcesses
Abstract interface implemented by a class that can process messages:
DebuggingMessageProcessor: Prints messages for debug as before
SMTPServer: As before
SMTPProcessor: New (below)
SMTPServer:
Regular listen/accept thread running a typical multi-connection/
session SMTP server.
SMTPProcessor:
Single-session SMTP 'server' - processes a single network connection
provided (accept()ed) by some other code i.e. tcpserver)
PureProxy:
As before, simply dump message unchanged to "smarthost" delivery
method.
VDomainProxy:
Performs TMDA processing on message before forwarding (injecting)
it to "smarthost" delivery method. Has knowledge of virtual domains
of authenticated clients.
VDomainProxyServer:
Multi-session PureProxy SMTP server with vdomain knowledge.
(Multiply inherits from SMTPServer & VDomainProxy. No code)
VDomainProxyProcessor:
Single-session PureProxy SMTP server with vdomain knowledge.
(Multiply inherits from SMTPProcessor & VDomainProxy. No code)
TMDAProxy:
As before, perform TMDA processing on message before forwarding
(injecting) it to "smarthost" delivery method.
TMDAProxyServer:
Multi-session TMDAProxy SMTP server with vdomain knowledge.
(Multiply inherits from SMTPServer & TMDAProxy. No code)
TMDAProxyProcessor:
Single-session TMDAProxy SMTP server with vdomain knowledge.
(Multiply inherits from SMTPProcessor & TMDAProxy. No code)
Perhaps TMDA* should be in the file before VDomain* and VDomain*
should be renamed VDomainTMDA* to make it more obvious what functionality
they have.
4. Updated main() to pick the correct one of:
VDomainProxyServer:
VDomainProxyProcessor:
TMDAProxyServer:
TMDAProxyProcessor:
depending on which of one_session and vhomescript are set.
I've tested the original changes in TMDA 0.84 using Python 2.2 and the
current patch against TMDA 1.0 using Python 2.3.3.
tmda-ofmipd-tcpserver.patch
Description: Binary data
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
