Rejecting some recipients after DATA?

Vernon Schryver vjs@calcite.rhyolite.com
Sat Apr 20 22:43:56 UTC 2002


> From: "Brian J. Murrell" <dcc-list-in@interlinx.bc.ca>

> ...
> Maybe this will prevent "yucky" from turning into "disaster".  This
> logging of mail that is bulky but not whitelisted is a dccm feature
> IIUC?  I have only been using the dccproc interface (and not dropping
> any mail yet) so maybe that's why it would look disasterous to me at
> this point.

`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]]


> ...
> Right.  This is the crux of it all.  An SMTP extention that did allow
> a success/failure PER recipient would be nice.

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.


> ...
> > I don't think sendmail would need or could use such a command line
> > mechanism,
>
> Indeed not.  But it would be nice for the admin.  I just want to be
> able to "reuse" Sendmail's DSN bounce code.

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.

> ...
> I am not familiar with Milter because I don't have Sendmail listening
> on port 25.  Like others here, I don't trust it enough.  I use a
> hacked versio of Obtuse' SMTPD as well.

Since you guys keep saying that, I can't keep quiet.  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. 
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.  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.  Call me experienced
or cynical as you please, but someone saying "it's [more] secure" only
makes me grumble "oh yeah? prove it."

Ever time I notice things about the supposedly faster 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.


> ...
> > One of the reasons I'm trying not to think that unthinkable thought is
> > that I've recently seen Internet-Drafts about DSNs.  I fear DSNs are an
> > infinitely deep and wide swamp and best handled by someone, anyone else.
>
> RFC 1892 and 1894?  I have not read through 1894 all the way, and it
> does look longish, but I doubt every case in there applies to us.

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.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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