Subject: Re: Last Call: Anti-Spam Requirements on an SMTP MTA to BCP

From: Gunnar Lindberg <[email-masked]>
Date: Thu, 5 Mar 1998 07:36:41 +0100 (MET)

Randy, instead of trying to be funny I should have given you a
serious answer. Now, Ned came back with a much better response
than I could ever have created and I hope that makes up for it.
Anyway, I'm sorry.

Then I need to raise a question. It may turn out to be a re-phrase
of what Ned has already said several times, but I need to make it
in my own words and get an answer back.

There are two issues here:

    1)	The functionality that MUST/SHOULD/MAY be in the MTA.

    2)	The way a sysadm makes use of this functionality.

The document is intended to describe 1) (which seems hard enough,
given the size of my anti-spam folder, compared to my spam folder).

It is not intended to describe 2), since that would really open
up a whole barrel of worms - telling each and every sysadm on the
Internet how to operate *his* mail system... No way.

In the document there is a section on anti-relay and there is even
some algorithm on how to do that. Lets assume it's OK. Since it
cannot be built into the MTA who you trust, a sysadm can easily make
his paricular MTA relay-open by simply "configuring accept all".

There is a section on log files and it has been pointed out that
they provide for a denial of service attack. Sure, but then the
sysadm can redirect to /dev/null - and an MTA that *has* good logs
redirected to /dev/null is much better than one completely without.

There is this idea of a (DNS) sanity check of "MAIL From:". Well...

And, there is the famous section on Return Codes. There are some
things that need to be carved in stone - DNS TempFail = 4xx - but
there are a lot of other situations where your mileage varies, i.e.
it cannot be carved in stone what is the "correct" value, neither
in the document nor in the actual MTA implementation.

So, how does one handle this in the document? Require MUST/SHOULD
for various options with the additional info that the sysadm MUST
be able to configure it, e.g. turn it of/off, define Return Codes?
And, what amount of config examples should be provided?

	Gunnar

---

From: Randy Bush <[email-masked]>
Date: Wed, 4 Mar 1998 23:17:32 -0800 (PST)

> given the size of my anti-spam folder, compared to my spam folder).

and folk seem in agreement that this is existing practice.

> Internet how to operate *his* mail system... No way.

i guess you have not seen tom k's grip document.  and these also apply
to mail systems run by women and the ambivalent <smirk>.

> be able to configure it, e.g. turn it of/off, define Return Codes?

that, imiho, is a matter of opinion, and does not affect how the
document should be classified.  personally, i would mandate the
configurability (not configurations) we know to be good practice and
define return codes.

> And, what amount of config examples should be provided?

my taste in this area is known to be on the left tail, very near the y
axis.  so don't ask.

randy

---

From: [email-masked]
Date: Thu, 05 Mar 1998 10:24:00 -0500

> Internet how to operate *his* mail system... No way.

There is an important section 2A) that needs to be written - discussion
of ways you should NOT in general use some given functionality.  As
we've seen, we've encountered cases where the MTA provides some feature
in the MAY/SHOULD/MUST categories, which an unthinking sysadmin then
misuses for another purpose.  We may indeed need a "laundry list"
of "Feature W is provided for reason X, you MUST/SHOULD NOT use it
for Y because then bad thing Z happens".

I need a ruling from the judges here:  Should such a section be
part of a BCP document, or should it be a seperate Informational?
RFC1912 "Common DNS Operational and Configuration Errors" is in the
Informational status - should a 'Common E-mail config errors" be
there as well?  Also, if a seperate document, is it permissible
for the BCP document to cite it (probably in a "Go read RFC20xx for
explanitory text" sense)?
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech