On May 16, 2009, at 11:55 PM, Richard Chycoski wrote:
Using standards to detect spam is a problem, too. Just because a
mail generator doesn't meet the full 'letter of the law' does not
mean that it is generating spam.
Again, *we* don't view it as a spam-detection methodology at all, and
do not promote it as such. When asked directly, we'll tell you that
the SpamAssassin folks noticed some statistical correlation between
"standards compliance" and "spamminess" but never high enough for an
RFCI test to generate the full complement of points needed to
instantly qualify something as spam.
It is important to deliver valid mail even from systems that are
substandard.
Not true. It is important to deliver, OR TO RETURN AN ERROR MESSAGE,
which is what the standards say to do.
David Lang then said:
who can honestly claim that every system they have ever run has been
100% in compliance with _ALL_ RFCs at all times?
for any that are tempted to say that they are, what about when new
RFCs are published, how long does it take to get into compliance
with them?
for those who believe that everyone should be following them 'or
else', how long should you be allowed to take to get into compliance
with a new RFC?
are there some RFCs that are more important than others?
In our case, we're not looking to "enforce" ALL of the hundreds?
thousands? of mail-related RFCs. We've cherry picked a few that we
think are important and (judging by our constituent users), others
seem to agree:
- Do you accept mail to postmas...@yourdomain?
- Do you accept mail to ab...@yourdomain?
- Does your inbound mail server accept DSN messages with the null-
envelope? (e.g., can I deliver a bounce to you?)
- Is your WHOIS information accurate?
- Are your MX records valid? (e.g., the MX RR doesn't have an IP
address in it, or point to a host that has a CNAME instead of an A
record, and you're not referencing RFC1918 space on the public net,
etc., etc.)
For the most part, it's very hard to say that there is some "technical
limitation" in any well-designed, or even moderately-designed, mail
system that would prevent a user from being "compliant" on these
points. In fact, what we consider one of our biggest "wins" was that
we made IMail users so irate that the vendor finally changed their MTA
so that it would no longer "Reject mail from <> (to combat the spam
problem)" without jumping through a lot of hoops and warning you that
it was a Really Bad Idea. Coming from that being the default value to
being something that you really had to consciously know what a bad
idea it was, was definitely a "win".
but when dealing with the outside world the purpose is almost always
to allow everyone to communicate with you, so it's seldom the right
thing to be strict.
Sometimes, "tough love" is important as well, though. Sometimes, for a
community of mail servers to interoperate well with each other, you've
got to set a bar somewhere as to "some basic level" you insist upon,
for the good of the community's future success. It can't simply be
anarchy, and everyone making exceptions for every new product that
rolls off the line and wants to do things differently, or having every
site have a different means of tracking down mail delivery issues that
you've got to somehow intuit from 4000 miles, two continents, and one
language barrier away. Sometimes, you have to simply say, "this is the
minimum you need to do before you're allowed to consume my local mail-
server resources."
And in the case of the DNSBLs we provide, I don't - for myself - think
that bar is set all that high. Sites are, of course, free to use/not-
use whichever zones they want.
Cheers,
D
_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
