ricefowler.com : a newly re-registered domain (Feb 2006) If you are looking at this page, you are probably here, because: You are an individual: ---------------------- - You got random spam with a @ricefowler.com return address and were curious. Yes, this domain seems to be hardcoded into some widely used spamware by default. Blame your ISP's spam defenses for accepting that mail to begin with - their anti-spam filtering doesn't seem to live up to its full potential. You can stop reading here. You are the administrator of a mail server (MTA). ------------------------------------------------- - You are running an MTA and got outgoing mail queued up for this domain, which you can't deliver. All mails are NDR's (non-delivery receipts) due to your inability to deliver the mail locally (unknown user, spam filters, any reason). The mail content is spam, or has spam-like properties, but you accepted them on your inbound MTAs anyway. Yup. The mail flow for this domain is massive and exceeds our current resources, prompting us to set a Null-MX most of the time to indicate that this domain does not originate mail (nor is any deliverable to it). We may, at one time or another, opt to not have any A/MX record at all. See http://ietfreport.isoc.org/idref/draft-delany-nullmx/ - You are running an MTA and got a SpamShield alarm notice, or got one forwarded by your ISP's Abuse/Security department, and found your MTA blocked for 3-5 days. When we actually do turn on the MX for brief periods of time, we do so to test SpamShield's capabilities to deal with the massive flow - not only is blocking/firewalling/blocklisting the intended outcome, but so is notification of the responsible sender ASN to get the abuse stopped: we sent 120,000 such mails every year since 2003. Clearly, ricefowler.com is pushing us over any scalable boundaries for notifications right now. We are estimating mailflow for this domain to generate 500,000 SMTP connections PER DAY aimed back at us, with 1 to 1.5 Million attempted mail deliveries to non-existing users over here - this brings us into the same mail volume league as a mid-to-large-sized regional ISP. 95% of this flow is from MTAs, improperly accepting&bouncing back mails they cannot deliver locally for any reason. That's in 2006, when 99% of all spam/virus/worm mails bear a forged return address: bouncing back means victimizing innocent parties! Read: this behavior is no longer operationally sustainable, nor acceptable, EVEN THOUGH IT IS RFC-COMPLIANT per RFC2821. A reminder: open smtp relays were RFC-compliant once, too. RFC821, released in 1982, was tolerating them as possible configurations, but the practice became operationally unsupportable around 1998 due to massive spammer abuse. Even the superceding RFC 2821, released in 2001, addressed this barely in section 7.7, saying MTAs SHOULD implement capabilities to restrict relaying. RFC2821 subsequently shoots itself in the foot in section 3.7 by specifying that the MTA (after accepting a message that later turns out to be undeliverable) 'MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse- path)' Clearly, security considerations and operational reality were not on the minds of this RFC's author - and massive virus-caused blowback didn't move into the public eye until about 2004. For these and additional considerations on 'blowback', please read the longer article at: http://forum.spamcop.net/forums/index.php?showtopic=203 - Could this possibly get my domain listed on anti-spam lists? Again, see the article above. - Your MTA keeps getting blocked by AOL. Yup. And massive accept&bounce 'blowback' into their MTAs can really piss them off. We are kinda on the same path as AOL with this. Roundup: please configure your MTA to not further victimize others in response to abuse taken by a third, malicious party.