On Sat, Jun 28, 2008 at 06:18:44PM +0200, Phil Regnauld wrote:
Rich Kulawiec (rsk) writes:
I don't see a problem with not accepting mail from clueless ISPs or their customers. The requirement for rDNS has been around for decades. Anyone who's not aware of it has no business running a mail server.
Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC.
There are de jure requirements (e.g., RFCs) and de facto requirements (e.g., best practices). de jure: RFC 1912, I believe, indicates that all Internet hosts should have rDNS. de facto: attempting run a mail server without rDNS is increasingly a losing proposition, as everyone with any clue at all is refusing all mail from such misconfigured/broken/ hijacked hosts.
Reverse DNS is not.
Not directly, unless delegated, of course. But mail server operators who choose incompetent/lazy/cheap ISPs should not be surprised if they are given incompetent/lazy/cheap service. Quality ISPs are well aware of the de jure and de facto requirements and have no problem meeting them.
"known-dynamic" is extremely up to debate. Frankly, blacklisting entire /16s because individual customer PCs have been hijacked is absurd, but I guess colateral damage is acceptable.
There is no such thing as "collateral damage" because there is no such thing as "damage" in this context. I explained this in detail on the ietf-asrg mailing list a couple of months ago. And given that any estimate of hijacked systems under 100 million is laughably out-of-date, it's a best practice to blacklist ALL such IP space and namespace pre-emptively. There's no point in waiting for evidence of abuse to show up: it's inevitable. End user systems should either be using their designated outbound mail relays *or* submitting on other ports with authentication.
Probably bounces will be the next thing to disappear.
Bounces *should* disappear, since it's a best practive to always reject (during the SMTP conversation) and never bounce. Failure to do so leads to outscatter, which is spam, and to blacklisting of the emitting hosts.
The operators don't care. The customers do. The customers don't have a choice, often. So you're right, the operator is not troubled that their customer's mail is being rejected.
Then that's a matter between the customer and the operator. Customers who have chosen poorly are likely to have issues. Customers who have not availed themselves of other options (such as a third-party relay through a host whose operators actually knows what they're doing) will get...what they get.
I'm not the one of the people who thought .info was a good idea (what, domains in other TLDs don't provide "information"?) I'm not the one who decided to sell domains in that TLD to spammers by the tens of thousands, thus effectively devaluing it for everyone else.
Because .org and .com don't do that as well ?
I see a fundemental difference here. .org is for organizations, .com for commercial operations, .net for network service operations. I see valid uses for those. I see none for .info. Its main reason for existence is to provide a cash cow to registrars.
Don't go preaching it as a best practice, though.
<shrug> It's been a best practice for years. ---Rsk