Rejecting some recipients after DATA?

Brian J. Murrell dcc-list-in@interlinx.bc.ca
Sun Apr 21 00:17:42 UTC 2002


On Sat, Apr 20, 2002 at 04:43:56PM -0600, Vernon Schryver wrote:
> 
> `dccm -t` and `dccproc -c` are very much the same under the covers, 
> including doing logging.  The would look more similar if I had not
> already used -t when I gave up and added rejection thresholds to
> dccproc.  Both expect an argument of the form type,[log-thold,][rej-thold]]

Indeed.  I have not started to use dccproc -c yet.

> It would be useless because you could not rely on it being supported
> by the ancient, minimal SMTP client that the CEO is using to send
> an "all hands" message.

Of course.  I was thinking of the "ideal world" when I shot that one
out.  :-)

> That's good thought, but unless there is already a trick, perhaps
> with `sendmail -f`, it sounds unlikely to catch the attention of
> the people working on sendmail.

Again, I agree with you on that one.

I wonder if they would take it as a patch?  Wouldn't be too difficult
I would think.

> Since you guys keep saying that, I can't keep quiet.

I didn't really want to get into a Sendmail vs. whatever debate, but I
guess here we go.  :-)

> It strikes me
> as foolish to rely on code that has been around fewer decades than
> sendmail and reviewed for security problems by far fewer people. 

Well all of that does not seem to have helped Sendmail at all.
Obtuse' SMTPD has a couple of advantages:

- it does one thing, SMTP serving; it is not trying to be the swiss
  knife of e-mail
- it does the "dangerous" parts (receiving data from the remote) in a
  chroot so that it does not have access to sensitive data should
  there be an exploit in it
- it is small enough that it can actually be reliably audited

> At best you can hope to escape attack for the same reason the commercial
> port of sendmail I was responsible for didn't notice the Morris Worm
> despite my leaving debugging turned on.  That was because mine wasn't
> for the most or second most common platform on the net.

Well if that is a benefit, I'll take it.  It is not the benefit I am
relying on however.

> Except for
> that "minority defense," all of the security advantages over sendmail
> that I've heard of for smtpd and all of the other alternatives are
> somewhere between uninformed optimism and snake oil.

I disagree.  Sendmail is a behemoth and as such it's more difficult to
audit.  Additionally it is constantly having new things "hung" onto
it with every new feature a potential security hole just waiting to be
exploited.

> Call me experienced
> or cynical as you please, but someone saying "it's [more] secure" only
> makes me grumble "oh yeah? prove it."

Well, since it's my system and I have looked over the code for smtpd
(something I could never imagine doing with Sendmail and ever staying
up to date with the code base) that is a decision I get to make.

> Ever time I notice things about the supposedly faster

Faster has got nothing to do with it.  Indeed, smtpd uses sendmail as
it's backend delivery agent, once it has processed the data received
from the remote and sanitized it.

> sendmail
> alternatives that simply cannot be made fast such as zilions of
> fork()/exec()s per message, my doubts about the accuracy of all of
> the claims for the alternatives grow.

That is because I never made claims of speed.  I know I am taking a
performace hit using an SMTP proxy, but one I feel is necessary given
Sendmail's history.

> No, not RFCs from the distant past but I-Ds within the last week or
> perhaps two.  I can't find anything that looks likely on ftp.isi.edu,
> but I don't think I was hallucinating.

But I would think we/I would implement (the relevant portions of) the
two standards track RFC and leave the I-D until they become standards
(headed at least).  Maybe some software for fully implementing what
the I-Ds deal with will surface by then.

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/20020420/f4409930/attachment.bin>


More information about the DCC mailing list

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