[Mailman-Developers] an opinion about using port 25

[Ken Manheimer]

On Thu, 23 Jul 1998, Scott wrote:

> Something's been bothering me about the use of connecting to port 25 to
> deliver mail.  
> 
> The goal of this endeavor, if i remember correctly, was to make
> mailman more portable in it's interface to MTA's.  However, I think
> that it may well make that problem even worse, and that it lies
> outside what mailman should be doing.
> 
> Here's the argument:
> 
> mailman is a mailing list manager, not an MTA.  If mailman developers
> decide to make delivery occur by SMTP, it has to do a LOT of the work
> that an MTA should be doing:  queuing messages, retrying every so
> often, bouncing messages with appropriate messages under appropriate
> circumstances (like deferral messages every 4 hours, etc).  All this
> should be the work of the MTA.
> 
> I also think that it will eventually exacerbate the problems of
> portability.  As a part of test group for a new MTA, and an
> administrator of a qmail and a sendmail system, I know many
> work-years of labor goes into making an MTA be able to successfully
> deliver mail to all the other MTA's out there.   This happens because
> different MTAs act very differently.  There are still problems
> occuring between code as mature as qmail and other MTA's like certain
> microsoft based products (postoffice, LSOFT for nt, etc).
> 
> Do we really want to take on that burden?

Most definitely not!  While i adamantly agree that Mailman should not be
taking over the duties of an MTA, i do not believe that the recent
change amounts to that. 

The change is in the way that Mailman passes messages to the *local* MTA
- it uses SMTP instead of execing the MTA program.  This falls far, far
short of the general problem of delivery to a general host out on the
net. The local MTA still handles all the challenges of getting the
messages to the remote site!

There are a few significant benefits to this change.  Directly contrary
to Scott's next point, this drastically reduces portability burdens,
because Mailman doesn't need to know *anything* about the specific MTA
the local host is running, except that it obeys SMTP. 

Another big benefit actually addresses the concerns Gergely Madarasz
(urgently) raised yesterday.  By using the specialized protocol, we
don't need to expose any of the addresses or other incidentals to
processing by the system shell.  (The addresses were still being exposed
in other popen's, further upstream, but i changed that in the
development code, which should be released soon.  I did a quick check
for other os.popen's and and os.systems, and most looked safe, but we
still have yet to do a thorough examination for security sake.)

There are related literal-mangling problems associated with exposing
strings to the shell, which we also circumvent by direct protocol
transmission.

This change may also enable us to exploit advanced SMTP capabilities,
like the DSN mod that dan ohnesorg has proposed (inhibiting those
annoying "Warning: not yet delivered after 4 hours, will keep trying
(and telling you about it)" messages). 

There are two drawbacks i can see to this approach, both easily
surmountable. 

One is that we *do* have to make provisions for systems where the MTA is
not always available.  This amounts to a drastically scaled-down version
of the general delivery-to-an-unavailable host, and has none of the
nuances of the more general problem.  It is addressed in the working
code.

The other is in handling delivery failures for destinations that happen
to be local to the local MTA.  These are the only deliveries that will
be immediately recognized and refused.  In this case we don't get the
benefit of bounce messages to recognize bad recipients, and we have to
make sure that the deliveries to valid recipients on the local host are
not disrupted.  The latter part has been taken care of in the working
copy, and the former part has to be, but no great disruption is caused
by it, in any case.

> There are other ways we could pursue this.  There are basically 2
> interfaces to an MTA mailman has to consider: updating aliases and
> delivering messages.  For each of these interfaces, we could create a
> class hierarchy into which mailman's communication with new MTA's
> could be easily dropped.  Such a structure, coupled with good
> documentation about how to add support for a new MTA seems to me like
> it will go further faster than putting a lot of work into SMTP
> transactions.   Such an approach could even include smtp transactions,
> as a bonus for the daring or those who want mail delivered via a
> separate machine than the one on which the list manager resides.  

I don't agree.  I'd rather solve, once and for all, connecting via SMTP
to the local MTA, and having to handle queueing messages at times the
MTA is unavailable, than developing a general plug in framework for a
command-based interface with every MTA that's ever going to come down
the road.  That doesn't sound like an tidy problem to me.

Ken