-- On Saturday, May 10, 2008 6:15 AM -0700 Eric Rescorla <ekr at rtfm.com> wrote regarding Re: [rt.amsl.com #7269] ietf.org mail blocking? --
>> > It should be the case that the IETF servers do not take >> > messages from hosts that do not exist. >> >> 1. The host does exist. It just doesn't have a DNS entry. >> 2. Why should this be the case? > > While the host may certainly exist, presence in the DNS is > commonly used as a weak authoritative existence test. The > assumption is that a process, albeit a weak one, was exercised > to approve the presence in the DNS. > > The obvious counter-argument is that a SPAMMER could own the > domain they're using and put anything they want in the DNS. > The argument is valid to the extent that SPAMMERS are not > taking steps to hide their existence or identity. While there > are many ways to slice the "email pie" to find the bad parts > (the SPAMMERS), I think we can at least agree that connection > sources who are attempting to hide their existence or identity > are SPAMMERS. Well, I'm not a spammer, so either this assertion is wrong or people not representing correct identities is a lousy test for people attempting to hide their existence. Take your pick.
I don't really want to pick either one. Instead, what I do know is that for any given SPAM check, it may or may not work in any given environment.
So, on the one hand, while you may not be a SPAMMER, you exhibit SPAMMER behavior as far as this rule is concerned. On the other hand, perhaps this rule is inappropriate for the IETF because the behavior it identifies is common among IETF participants. In that case, the rule should be removed.
Glen has already removed the rule for the IETF server so the immediate problem is resolved.
Notwithstanding the principle of being liberal in what you receive, I believe it's reasonable to expect a minimum of best practices from implementations. Mitigating SPAM is tough enough and this is easy to do. Of course, this is a case where the "best practices" are informally stated at best, which I believe is the real issue.
Although this won't qualify as "best practices", per se, but I do believe that the IETF should document completely and exactly what it does with respect to security and protection. Doing this would provide a foundation for having this discussion about what is and is not a good idea for the IETF. Note that this is not about whether the practice itself is good or bad, since that will vary with different environments, but whether the practice is good or bad for the IETF.
> For those cases, this test is just one mechanism among many > that is helpful in the fight against SPAM. Huh? Why is this so? Say I do "EHLO mail.ietf.org"? That's a perfectly valid domain name and it maps to an IP address. It just doesn't happen to be mine. This only becomes a useful check when you compare it to the address that I'm actually coming from.
You're right. The HELO check, by itself, just to see if the domain name is listed in the DNS is pretty weak but, again, taken all together, checking "minimum best practices" is effective. There's a list of about dozen checks on incoming email that the IETF server does before deciding to accept a message. And then there's a dozen more before deciding if a message is to be distributed.
Failing certain ones gets you an immediate rejection or, in the case of SPAM that has already been accepted for delivery, the message gets "dropped."
We can debate whether the minimum in the case of the HELO check is "check for a DNS listing" or "check that the forward and reverse mappings match". This is one of those cases where, in my experience, different environments tolerate different choices. The IETF does not check that the forward and reverse mappings match, only that a forward map exists. Or, it did until this weekend.
>> > The IETF does not apply strict connection controls but it >> > seems reasonable to me to reject apparently "anonymous" >> > messages. >> >> What makes the message anonymous? I'm advertising >> "ekr at rtfm.com" in my MAILTO. > > I'm using "anonymous" to mean that the origin of the connection > is not clearly identifying itself. Yes, it could "lie" to get > past this particular check but that's exactly the point. It's > not even trying to "do the right thing". I don't find this particularly convincing. It's identifying itself by IP address. Given that that's a lot harder to spoof than domain name, I wouldn't use the term anonymous...
To be strict, you were not identifying yourself by IP address. The connection can be identified by its source IP address but that's a separate test. We're talking about the domain name in the HELO.
You were identifying yourself with a FQDN that was not listed in the DNS. Had you wanted to identify yourself with a domain literal instead that probably would have worked.
Jim