Rejecting some recipients after DATA?

Brian J. Murrell dcc-list-in@interlinx.bc.ca
Sun Apr 21 04:37:31 UTC 2002


On Sat, Apr 20, 2002 at 09:02:38PM -0600, Vernon Schryver wrote:
> 
> I'm trying not to get into an MTA war, but can't resist one more reply.

RESISTANCE IS FUTILE!  You will be assimilated.  :-)

> Off hand, I can't think of anything that sendmail does that isn't required
> by people like you (intending no offense).  Regex's, filtering of all
> sorts, vacation programs and delivery to other programs, LDAP, SMTP-AUTH,
> SMTP-TLS, and so on and so forth are not optional.

A lot of that *I* don't need.  If I were installing an enterprise mail
system, well, yes then I might.  But I would also wrap that soft chewy
center with a nice crunchy hard shell.

I really don't like letting somebody inject data directly into that
complicated system without a proxy validating the data.

I also find smtpd's rules much more flexible than I ever did
Sendmail's, but I will admit since using smtpd, I have not looked at
Sendmail's rules lately.  I also feel more confident hacking on smtpd.
I can see the effects of my changes.  I fear the ripple effects of my
changes on Sendmail and I don't really feel like learning the whole
codebase of Sendmail to add a few hacks and hope I have not left a
gaping security hole.

> The big sendmail holes I recall have not involved receiving data
> from the network, but delivering mail locally.  It's hard to have
> a security hole while doing only the on-the-wire part of SMTP.

Uhm, buffer overflow?  I seem to recall only just recently (in terms
of Sendmail's life) a buffer overflow with respect to processing
headers, or was it just input lines in general?  In fact one of the
sanity checks that SMTPD does is on the length of any given line of
input.

> It's harder to do all of the fancy and strange delivery stuff
> everyone demands without having gapping holes.

Agreed.  I just don't want the gaping holes in my front door.  Better
a hole within my "house" than right at the front door.

> You must be root to use port 25 on must UNIX-like systems, and
> you must some special privileges to write to users' mailboxes.

[x]inetd provides the binding permission and like I said earlier,
Sendmail provides the backend delivery, once the data has been
sanitized.

> The new sendmail scheme of not using SUID and having a special
> delivery program may help, but I'm too experienced to be sanguine.

Ohmygawd, are you referring to that overly complicated system of
multiple .cf files and Sendmails listing on a whole raft of ports all
talking from one to the other?  Bah!  I spent the better part of an
evening try to get mail flowing again after installing that!

Did I mention Sendmail's past and recent complexity?  As if it was not
bad enough trying to get one .mc->.cf file working, now we have to get
two working, and if you have anything else listening on port 25, good
luck!

> Have you personally audited smtpd?  

Formally?  Nope.  Informally, yes.  But due to it's small size, it
does not need as comprehensive (large) an audit as Sendmail.  I am
relatively happy with the number of people hacking on it that it's
relatively safe.

> Tcpwrappers is not a bad package for what it does, but if you think
> wrapping IP addressed based ACL's around an arbitrary program makes
> it secure,

Of course it doesn't.  You won't actually see tcpwrappers in use on my
system because I agree with you in the amount of security it really
adds.

> That's a problem, but which MTA doesn't suffer from freaping creaturism?

None.

> How have you avoided sendmail's serious problems by gluing smtpd in
> front of it?

Good question.  Kinda like that statement that "90% of all security
breaches go completely undetected", or the request a friend of mine
got from his superior once "can you please have the computer generate
a report of all of the data that is not in the computer yet?".

Has SMTPD raised any red flags or fired up the klaxons, or gone to
Defcon 1?  Nope.  But have I been cracked through a Sendmail hole?
Again nope.

> Searching on http://www.cert.org for "sendmail" is or should be
> illuminating to those who honestly think that sendmail is full of
> holes.  Look at the dates and which of the holes involve SMTP and
> which involve delivery.

That might be true, and I have certainly been relaxing my guard on
Sendmail.  Perhaps it's history has afforded it better and more
conciensious development as of late (we could only hope that other
software and it'd developers took such hints, but let's not fork this
offtopic discussion into another one :-)

I have even considered a few times just running Sendmail on port 25,
but like I said, I find the format of the SMTPD rule file much easier
to grok that the Sendmail filtering syntax (again, which might be
better than the last time I looked -- but it was awful then).

Does sendmail currently allow you set up rules at differing
granularities from site-wide to domain-wide right down to individual
users?  Can a single recipient request one handful of dnsBLs, plus a
regex match list while another recipient uses a different set of
dnsBLs and yet another user wants no filtering at all?  Can different
destination domains have different filtering rules each acting as the
default for users who do not specifically set up their own customized
set of rules?

These should all be active at the envelope.  So if a given recipient
wants to block based on a dnsBL it gets blocked at the envelope, not
DSNed or /dev/nulled after receipt.

> I think sendmail's history measured in exploits per machine-hour or
> per SMTP transaction is orders of magnitude better than any of the
> alternatives.

Well if you are comparing Sendmail to Obtuse's SMTPD proxy (which is
not necessarily a fair comparison but it is the comparision that this
thread started with) then I would say that SMTPD is orders of
magnitude better than Sendmail.  I know of 0 exploits of Obtuse SMTPD.
How many does Sendmail's past have?

> P.S. Could I interest you in a constant sending address?  Each of
>   your messages requires manual approval.  I'm constantly affraid
>   I'll poke the wrong button and drop it.

I have forgotten to use my dcc-list constant address[1] a couple of times
but most of what I have sent in the last 3-7 days should be using my
dcc-list constant address, as this one will.  Do you still have to
approve the ones From: dcc-list-in@interlinx...?  You shouldn't have
to.  That is my subscribed address.

[1] Just have not wired the dcc-list-in address into my personality
    selection system yet.  The volume of my posting here has only gone
    up dramatically in the past few days.

b.

-- 
Brian J. Murrell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://www.rhyolite.com/pipermail/dcc/attachments/20020421/dc0a7fbc/attachment.bin>


More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.