On Sat, 16 May 2009, Richard Chycoski wrote: > Derek J. Balling wrote: >> On May 15, 2009, at 11:44 PM, Brad Knowles wrote: >> >> >>> on 5/15/09 6:59 PM, Derek J. Balling said: >>> >>> >>>> http://www.rfc-ignorant.org/ >>>> >>> ... many in the anti-spam community ... >>> >> >> This is, perhaps, the fundamental logic-flaw (and one we encounter >> daily, so you're not unique). >> >> RFCI isn't about "stopping spam". You won't even find the word spam >> anywhere on the web site. We simply don't care if it's an effective >> "spam measure" or not.
it's very heavily implied, even if not stated outright. >>> If you're doing this for your own domain, that's one thing. When >>> you're >>> running a mail server for someone else, or a community of people, >>> that's >>> something else. >>> >> >> I can think of several large communities (ginormous college campuses, >> for example) who use our services and do so for the same reason we >> started it (e.g., "we don't want to accept your mail if you won't >> accept our bounces with null-envelopes"). Like any form of mail- >> blocking, it's something you need to completely understand what you're >> doing before you do it, and have buy-in from management, etc., etc. >> But standards-compliance is important to a lot of people, and there's >> enough people who want to enforce it, that we've been able to stick >> around long after this grew too big to run on a DSL line from my >> apartment. ;-) >> >> Cheers, >> D >> > 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. > > Standards are broken all the time. Generators of mail should do > *everything* that they can to generate 'compliant' messages. Receivers > of mail should do *everything* they can to accept mail. This is the > reasonable thing to do, since not all generators of email are perfect. not to mention that they are managed and configured by humans. 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? personally I see RFCs as a good thing, and I do use them when arguing about how something should be designed and implemented. but I also look at the context of how things are going to be used, and I sometimes decide that doing something that's not RFC complient is better for the limited environment that I'm working in. there are also times where some applications that aren't RFC complient have features that are compelling enough to cause me to accept the fact that they aren't complient. sometimes this 'feature' can be simple performance, sometimes reliability, and sometimes it's additional things that it can do. I believe that qmail and djbdns are not fully RFC complient (or if they are, they don't implement many of the SHOULD or MAY sections), but within their limits they are very useful programs. > In the early days of RFC821/822, the BSD-and-related Unix systems were > notoriously bad at receiving mail according to the RFC standards. The > worst infraction was in the area of case sensitivity - the RFCs stated > that receivers needed to be case insensitive, yet the Unix > implementations were quite case-sensitive. The *mainframe* system that I > worked with (the Michigan Terminal System) was considered the best > conformance-checker on the planet, thanks to one Gavin Eadie who did a > marvelous job at turning the dictates of RFC 821 and 822 into code. The > result was a mail system that generated messages 'to the letter' while > accepting 'crud and whatever' from less-than-compliant systems and > delivering it through rain, snow, hail, sleet, snarks, abends, etc... > > It is important to deliver valid mail even from systems that are > substandard. People depend upon these communications, and failing to dot > an i or cross a t should cause the mail to fail. Source or content is a > different matter, using that to determine SPAM status has its > justifications. Poorly implemented mail servers (of which there are many > in this world) should not prevent the e-letter carrier from making her > or his appointed rounds. Just because everybody doesn't run sendmail, > exim, or Exchange, it shouldn't stop their mail from getting through - > even if that makes an easy mark for spam detectors. there are times to be very strict with what you recieve, and there are times to be very forgiving in what you recieve. if you are in control of the sender, then having the reciever be strict serves as a very nice security measure (plus it's frequently simpler and faster to check if something is what you expect and throw an error if it isn't than to work around and fix up bad stuff) 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. David Lang _______________________________________________ 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/
