Re: Questions about populating RIR with customer information.
on Wed, Aug 01, 2007 at 09:47:45AM -0400, Drew Weaver wrote: Up until recently, we were only providing the RIR database with information about our larger allocations /24 or larger. We have noticed however that many anti-spam organizations such as Spamhaus, and Fiveten will use the lack of information regarding an IP allocation as a blank check to blacklist entire /24s when they are really targeting a single /30 or a /29. It's not just Spamhaus. How do you expect *anyone* to know whether an abusive customer of yours has a /29 or a /18 unless you *tell us* in rwhois? We happily block large swaths of the network due to failure on the providers' parts to adequately describe the allocation. rDNS scans and guesswork are fine, but it's much better if we can count on the providers' actual assignments as published in rwhois and block the smaller allocations instead. Is there some way that we can 'proxy' the information so that it simply states that the /29 has been allocated to a customer but it doesn't provide their contact information? Why on earth would you want to do that? In a world where 90%+ of our inbound mail traffic is abuse, I think accountability trumps privacy. Anyone using those stupid cloaked whois listings is automatic fodder for the filters here. Your right to access my resources ends when you deny me the ability to identify you if I so choose, on evidence of ill intent. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Blocking mail from bad places
on Wed, Apr 04, 2007 at 06:25:18PM -0400, John L wrote: This technique works great to keep spam out of your mailbox. Inline rejection is a little dangerous for mailing lists And for anyone else who doesn't feel like jumping through your hoops. Providing a telephone number in the bounce is an effective way to deal with false positives. Only if you assume that everyone who writes to you is so desperate to send you mail that they are willing to make what may be an international call in the middle of the night. I have not found that to be a very realistic assumption. I have to agree with John here - I've been sending back 'email me at [EMAIL PROTECTED] if this in an error' for all rejections here since 2003 or so, and can count the legit mail to postmaster I've received in that time on one hand, maybe two; the stuff that gets rejected before the accept postmaster default gets a different error, containing a phone number. I've never had anyone call me there. Not that it bothers me much - I've done my part, I figure, and if they aren't willing to email a postmaster or call, then shrug? What can I do? I'll add that even if everyone were willing to email/call with problems, the hideous things that (e.g.) Exchange does to your carefully handcrafted rejection errors are enough to cripple the least tech-savvy of your likely audience, anyway. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
resnets and naming (was: Re: botnets: web servers, end-systems and Vint Cerf)
on Fri, Feb 16, 2007 at 07:43:38AM -0500, Eric Gauthier wrote: Dorms are basically large honey nets. :) I run the network for a University with about 12,000 students and 12,000 computers in our dormitories. We, like many other Universities, have spent the last five or six years putting systems in place that are both reactive and preventative. From my perspective, the issues are still there but I'm not sure that I agree with your implications. Do we still have compromised systems? Yes. Is the number of compromosed systems at any time large? No. Is the situation out of control? No. Email me off-list if you want more details. IMHO, Its too bad broadband providers have not yet picked up on what the Universities have done. Hear, hear. It's also too bad that there are still so many .edus without rDNS that identifies their resnets and dynamic/anonymous space easily, though the situation seems to be improving. Not knowing which .edu is yours, I'll refrain from further comment, but I will give some examples from some that I know about: Good examples: [0-9a-z\-]+\.[0-9a-z\-]+\.resnet\.ubc\.ca [0-9a-z\-]+\.[0-9a-z]+\.resnet\.yorku\.ca ip\-[0-9]+\.student\.appstate\.edu r[0-9]+\.resnet\.cornell\.edu ip\-[0-9]+\-[0-9]+\.resnet\.emich\.edu [0-9a-z\-]+\.resnet\.emory\.edu dynamic\-[0-9]+\-[0-9]+\.dorm\.natpool\.uc\.edu Bad examples: resnet\-[0-9]+\.saultc\.on\.ca [0-9a-z\-]+\.(brooks|camp|congdon|cubley|graham|hamlin|moore|powers|price|townhouse|woodstock)\.clarkson\.edu [a-z]+\.(andr|carm|ford|laws|stev|thom|ucrt)[0-9]+\.eiu\.edu (linden|parkave|ruthdorm|ucrt|village)[0-9a-z]+\-[0-9a-z]+\.fdu\.edu resnet[0-9]+\.saintmarys\.edu [0-9a-z\-]+(aolcom|uncgedu)\.uncg\.edu ** (l[0-9]+stf|bl)[0-9]+\.bluford\.ncat\.edu The general idea is, as has been mentioned before, to use a naming convention that can easily be blocked in sendmail and other MTAs by the simple addition of a domain tail or substring to an ACL, such as 'resnet.miskatonic.edu' or 'dyn.miskatonic.edu'. As interesting it can be to explore the campus map trying to figure out whether a given DNS token represents a lab, the administration building, the faculty lounge, or a dorm, over and over again, there's gotta be some activity that is more rewarding in the long run, such as skeet shooting or helping people disinfect their computers (or, joy of joys - both simultaenously!) ** I'd like to single out uncg.edu for special ridicule here - I hope they're still not doing this, but at one point over the last three years at least, their DHCP addresses were comprised of the end user's email address, sans '.' and '@', AS THE HOSTNAME in an otherwise non-subdomained whole: e.g., '[EMAIL PROTECTED]' got the hostname 'britney1986aolcom.uncg.edu', '[EMAIL PROTECTED]' got 'billguncgedu.uncg.edu', etc. I'm sure the spammers who plague uncg.edu today didn't get their entire computer-literate student body's addresses through an rDNS scan. After all, not /all/ of the addresses were in uncg.edu. The rest were in AOLland or at hotmail or a few other obvious freemail providers. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ rambling, amusements, edifications and suchlike: http://interrupt-driven.com/
Re: AOL Non-Lameness
on Mon, Oct 02, 2006 at 06:45:46PM -0400, [EMAIL PROTECTED] wrote: On Mon, 2 Oct 2006, Rick Kunkel wrote: I had users that appeared to be getting their email blocked seemingly because in their sigs, they write their phone number that stupid IP-Address-Wannabe method, like: 206.555.1212 As an aside, is this something that's the norm in other places, like commas instead of periods for decimals in other countries? I'd hate to sound critical if it was. It just seems that I know a large amount of very American people who have decided that phone numbers with periods in them somehow look more hip than dashes. I despise that. Can you tell? ;) Do those people also put http://; in front of their phone numbers? If not, then AOL would reject any email containing an IP address in the message body for any reason. You've never seen anything like http://foo.example.com * 978-555-1212 * 978-555-2424 (fax) * FooBar Ltd. in a sig? Now how about in spam? URLs in spam are often so broken they're unusable in anything but the most forgiving mail clients, but that doesn't stop them from being spam, and it doesn't stop others from trying to detect them despite all their brokenness. Cut AOL some slack - they've been very responsive whenever I have had trouble with them, and they've been very responsive this time. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ rambling, amusements, edifications and suchlike: http://interrupt-driven.com/
Re: comast email issues, who else has them?
on Fri, Sep 01, 2006 at 11:45:53AM -0400, Sean Donelan wrote: For example, Gmail doesn't include the originating IP address in its email which makes it even more difficult for spam filters to judge its reputation. You misspelled makes it a veritable haven for 419 scammers. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ rambling, amusements, edifications and suchlike: http://interrupt-driven.com/
fingerprinting and spam ID (was: Re: ISP wants to stop outgoing web based spam)
on Fri, Aug 11, 2006 at 09:38:46AM +0100, Peter Corlett wrote: On 10 Aug 2006, at 22:07, Barry Shein wrote: [...] The vector for these has been almost purely Microsoft Windows. I wonder. From the point of view of a MX host (as opposed to a customer-facing smarthost), would TCP fingerprinting to identify the OS and apply a weighting to the spam score be a viable technique? Yes - I had a quickie p0f/sendmail fingerprinting check working here for a while; it was primarily amusing to watch the various versions of Windows scroll by as I watched the zombies attack, but given that the occasional legit mail server runs Exchange, and given that I already knew which hosts were zombies (generic rDNS, sending to traps, using laughably broken heuristics to try to defeat my filters, etc.) it turned out to be somewhat less than useful. Just amusing. Now that my filters have a scoring mechanism, maybe I'll go back and turn it back on and see how it works. The problem is that I already see enough legit mail hit the quarantine due to being HTML/multipart, suspected of being sent direct-to-MX due to Exchange's bizarre habit of not providing an audit trail via Received headers, etc. Knowing that it's a Windows box doing the sending is likely to be more of a reason to treat it more lightly, on the assumption that it's laughably broken but probably mail some employee wants/needs, than the alternative. IOW, if you're already ugly and smell funny, it doesn't help to know that it's also because your mother wears combat boots. The biggest problem with email isn't that it doesn't work; the biggest problem with email is that there are so many vendors who simply refuse to implement SMTP properly. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ rambling, amusements, edifications and suchlike: http://interrupt-driven.com/
rDNS naming conventions (was: Re: SORBS Contact)
on Thu, Aug 10, 2006 at 01:11:50AM -0700, william(at)elan.net wrote:
On Aug 9, 2006, at 1:06 PM, Matthew Sullivan wrote:
This is also why I took the time to create:
http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt
The reason I do not like RDNS naming scheme is because it forces
one particular policy as part of the name.
Fair enough. FWIW, I've seen a wide variety of naming schemes (I've
got a project that collects these as an antispam/anti-botnet measure,
and so far we've got around 16K conventions documented for 11K domains).
I've read and commented on the ID above; I think Mat's heart is in the
right place but his hopes are too high. Not just because his approach is
too English-focused (what of correo for mail? what of other i18n
variants for 'static' or 'dynamic'?) but because I've seen so many bad
examples of people using rDNS for nothing useful at all, I doubt they'll
suddenly wake up and realize hey! I could have encoded something
useful and meaningful into my PTR! But it's a start.
Among my favorites are those who feel it necessary to add 'rev',
'reverse', 'ptr', 'ip', etc. to the PTR along with some encoding of the
IP itself. People, we *know* it's a PTR. If we didn't know the IP, we
couldn't have looked it up, so it's rather fruitless to encode it in the
PTR, don't you think? I'm guilty of the same thing, as the IP does
provide a differentiator as well as a way to say {something}.domain,
or this IP is not used for anything in particular, but it's still
an area in need of some inquiry.
Ideally, speaking as a mail admin, I'd prefer that any given PTR have
some indication of:
- the assignment type and duration (short-term pool, long-term dyn,
static, etc.)
- the technology in use (dialup, cable, dsl, wireless, etc.)
- whether it's assigned for 'business' or 'personal' use (yeah, I
know, lousy distinction, but suggest a better one)
These are all useful for those who have to make judgement calls about
whether to trust output from a given source; this is true regardless of
protocol. It just happens that for some, email is in high relief; for
others, it might be IRC or Web spammers or SMS or ssh dictionary attacks
or whatever.
Of the 16K naming conventions I've got handy, over 100 refer to IPs
that are labeled in one manner or another as unassigned. Of course,
I collected them from spam I received here, but they're officially not
in use. Thanks! I guess I'll refuse all mail from them.
Over half are classified as 'generic' - namely, there is so little
useful information in them we can't tell whether they're dynamic,
static, residential, dialup/dsl/cable/wireless, or anything. Many,
in fact, just start with 'host' and end with some variant of the
IP address encoded into the PTR.
Only 682 of ~16K provide us enough information for us to judge them as
plainly 'static'. (There are a few other classifications that may
suggest static assignment, such as 'nat', 'vlan', 'lan', 'colo',
'webhost', etc. but that's just guesswork - 'dhcp' may strongly denote
dynamic, as may 'pool', but we've seen static DHCP as well as static
pools, whatever they are.) The most popular approach beyond the simple
host-foo seems to involve encoding geographic information into the
PTR; after that is perhaps advertising hosted.by.superwebhost! or
redundancy bigisp-foo-bar-baz.dyn.bigisp.net. Worst among those who
actually provide rDNS in SE Asia is probably tm.net.my, who name all of
their customer PTRs 'tm.net.my'. Hm. Maybe encoding the IP in the PTR
ain't such a bad idea after all, especially for tracking down mass
mailing viruses that HELO with the value of their PTR through NATs.
On the bright side, people seem to have mostly woken up to the idea
that if you're going to put static/dynamic identifiers into the PTR,
you need to do it rightwards, rather than leftwards e.g.
1-2-3-4.east-campus.resnet.dhcp.pool.dyn.miskatonic.edu
rather than
dyn-pool.dhcp.resnet-1-2.east.3-4.campus.miskatonic.edu
as the former is easily collected in formats such as sendmail's
access.db and doesn't require expensive regex overhead or many, many
entries to cover a single class of listing. I'm definitely seeing a
shift towards the former approach from the latter, though there are
always the jokers like 'dynamic_dsl_client.dsl.gol.net.gy' who woke up
and changed their _s to -s one day this year, but left the positional
aspects as is. And yes, that's the *full name* of the PTR, so at
least you can block it all with an access.db entry.
Your point below about having different schemes for policies in
different realms is on target, but doesn't mitigate the responsibility
of all ISPs to provide some useful information about their services to
remote systems; a well-designed PTR can do that as a first-stage effort
while we wait for $PROTOCOL's $ENHANCEMENT to stop $ABUSE to wend its
way through the standards committees and implementation.
My preference is that you lookup RDNS
Re: rDNS naming conventions (was: Re: SORBS Contact)
on Thu, Aug 10, 2006 at 08:55:37PM +0530, Suresh Ramasubramanian wrote: On 8/10/06, Steven Champeon [EMAIL PROTECTED] wrote: redundancy bigisp-foo-bar-baz.dyn.bigisp.net. Worst among those who actually provide rDNS in SE Asia is probably tm.net.my, who name all of their customer PTRs 'tm.net.my'. Hm. Maybe encoding the IP in the PTR There's at least one vietnamese ISP that has / had till recently set localhost as rDNS for all their IPs. IIRC, that was fpt.vn; they replaced 'localhost' with the incredibly useful: adsl-pool-xxx.fpt.vn adsl-fix-xxx.fpt.vn dialup-xxx.fpt.vn adsl-dynamic-pool-xxx.fpt.vn \d+-\d+-\d+-xxx-dynamic.hcm.fpt.vn host-\d+-xx.hcm.fpt.vn \d+-\d+-\d+-xxx-dynamic.hcm.fpt.vn Yes, the 'xxx's are literals. e.g., $ host 210.245.14.143 143.14.245.210.in-addr.arpa domain name pointer dialup-xxx.fpt.vn. Or it may have been hnpt.com.vn, who replaced it with e.g., adsl.hnpt.com.vn Again, not terribly useful for tracking leakage via NATs. $ host 203.210.213.149 149.213.210.203.in-addr.arpa domain name pointer adsl.hnpt.com.vn. But hey, at least they *have* rDNS, I suppose that's something. I agree that judgements based entirely on rDNS are troublesome. So, too, are the side effects of chemotherapy. But we're trying to save the patient before the miracle cures arrive, and right now email is very, very sick indeed. And rDNS is a useful tool especially in a scoring-based environment. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ rambling, amusements, edifications and suchlike: http://interrupt-driven.com/
Re: Who wants to be in charge of the Internet today?
on Fri, Jun 23, 2006 at 11:23:44AM -0700, [EMAIL PROTECTED] wrote: The users have an expectation that their access to the Internet works like a utility. When you say the power is shut off you don't expect to expand on whether the power grid in your state had a cascading failure but people on the other coast still have power and when your water supply is shut off does not mean that all the people in the world can't get a drop. It just means that her Internet is off and as far as she is concerned the whole Internet/Power/Water supply might as well be off Yep. I eventually just trained myself into hearing my Internet access when I heard the Internet from someone who doesn't know what the Internet is. e.g., s/Is the Internet down?/Is my Internet access down?/ YMMV, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ rambling, amusements, edifications and suchlike: http://interrupt-driven.com/
Re: Nuclear survivability (was: Cogent/Level 3 depeering)
on Thu, Oct 06, 2005 at 03:25:54PM -0500, John Kristoff wrote: On Thu, 6 Oct 2005 11:54:34 +0100 [EMAIL PROTECTED] wrote: While I realize that the nuke survivable thing is probably an old wives tale, it seems ridiculous that the Internet can't adjust by [...] It's not a myth. If the Internet were running RIP instead of BGP For the Internet, I believe it was indeed a myth. I wasn't there, but according to someone who was: http://www.postel.org/pipermail/end2end-interest/2004-April/003940.html I believe the mental-mythical sequence went something like: - some people (Paul Baran among them) were interested in ways to build communications networks that could survive lots of damage, and came up with the idea of distributed networks that could route through multiple redundant nodes - the US was in a cold war and nuclear arms race - a nuclear attack could inflict lots of damage to communications networks - the Internet was eventually, to some extent, built as a distributed network with routing through multiple redundant nodes (if nothing else, the protocols that ran it were capable of such) - the Internet was therefore built to survive a nuclear attack QED, HTH, HAND -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Computer systems blamed for feeble hurricane response?
on Tue, Sep 13, 2005 at 01:13:19PM +, Fergie (Paul Ferguson) quoth: Attempts by agencies to spur the Federal Emergency Management Agency into urgent action were met with bouncing emails, the Journal said. It quoted a Department of Health official as saying every email it had sent to FEMA staff bounced. They need a better internet provider during disasters, the Journal quoted her or him as saying. Does anyone know what their mail infrastructure looks like? From what I can see, they don't even have an MX record for fema.gov... -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Computer systems blamed for feeble hurricane response?
on Tue, Sep 13, 2005 at 09:54:42AM -0400, Mike Tancsa wrote: At 09:31 AM 13/09/2005, Steven Champeon wrote: Does anyone know what their mail infrastructure looks like? From what I can see, they don't even have an MX record for fema.gov... No MX record, and the A record for fema.gov does not accept smtp traffic. # telnet fema.gov smtp Trying 205.128.1.44... telnet: connect to address 205.128.1.44: Operation timed out telnet: Unable to connect to remote host # Then again, it might be that they use different email addresses ? @dhs.gov ? Their contact us page on fema.gov lists several @fema.gov addresses, so I doubt it. fema.govnameserver = ns.fema.gov fema.govnameserver = ns2.fema.gov ns.fema.gov internet address = 166.112.200.142 ns2.fema.govinternet address = 162.83.67.144 Looks Solaris'ish # telnet ns2.fema.gov smtp Trying 162.83.67.144... Connected to ns2.fema.gov. Escape character is '^]'. 220 ns2.fema.gov ESMTP Sendmail 8.11.7p1+Sun/8.11.7; Tue, 13 Sep 2005 09:49:36 -0400 (EDT) Well, how is any automated system supposed to find it? Sheesh. Apparently, that host accepts mail to postmaster; we'll see if it is actually delivered/read/responded to. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Tidbit from DirectNIC
on Fri, Sep 02, 2005 at 04:44:49PM +0100, [EMAIL PROTECTED] wrote: From downtown New Orleans... http://www.livejournal.com/users/interdictor/ -snip- Fox News is reporting that there is an operation underway to refill chillers at the Bell South building down the street to keep phone service available to much of the southeast United States. That is apparently where all the firetrucks are going to in the area, in case you were wondering. -snip- It is interesting to note that it is possible to bring in diesel and water to resupply BellSouth yet it is impossible to bring in water and food for the residents, not to mention a fleet of small boats that could have prevented thousands from dying trapped inside their attics. 1) potable water is probably somewhat different from the water used in chillers or fire trucks 2) phone service is, IMHO, one helpful pre-requisite to providing emergency care and disaster relief 3) the pictures I've been seeing have been full of boats, many of them thrown up on land a few hundred feet from their berths Not saying that the utter failure of DHS as an organization isn't on evidence here. Just saying that it's one thing to feed and water a plant and quite another to feed and water a human being, let alone tens of thousands of them. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Blocking certain terrorism/porn sites and DNS
Can someone point me to a mailing list that discusses netops? I seem to have stumbled across the net.kook terrorism rant list by accident. Thanks! -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Verizon is easily fooled by spamming zombies (was: Re: VerizonWireless.com Mail Blacklists)
on Wed, Jun 01, 2005 at 12:07:33PM -0400, Rich Kulawiec wrote: (As to Verizon itself, since three different people pointed out the relative lack of SBL listings: keep in mind that SBL listings are put in place for very specific reasons, and aren't the only indicator of spam. Other DNSBLs and RHSBLs, e.g. the CBL, use different criteria and thus provide different measurements (if you will) of spam. So, to give a sample data point, in the last week alone, there have been 315 spam attempts directed at *just this address* from 194 different IP addresses (list attached) that belong to VZ. Have I reported them? Of *course* not. What would be the point in that?) snip evidence of astounding lack of clue of VZ's customers Zombies I expect; what's worse is that they're /obviously/ not even doing the most basic checks: Received: from verizon.net ([63.24.130.230]) (63.24.130.230 is 1Cust742.an1.nyc41.da.uu.net, HELO'd as 'verizon.net' and VZ still relayed it) Received: from verizon.net ([68.130.237.39]) (68.130.237.39 is 1Cust39.tnt26.mia5.da.uu.net, HELO'd as 'verizon.net' and VZ still relayed it) Received: from verizon.net ([68.130.237.35]) (68.130.237.35 is 1Cust35.tnt26.mia5.da.uu.net, HELO'd as 'verizon.net' and VZ still relayed it) Received: from verizon.net ([65.34.38.26]) (65.34.38.26 is c-65-34-38-26.hsd1.fl.comcast.net, HELO'd as 'verizon.net' and VZ still relayed it) Received: from verizon.net ([65.34.184.15]) (65.34.184.15 is c-65-34-184-15.hsd1.fl.comcast.net, etc.) IOW, VZ isn't even checking to see if a zombie'd host is forging its own domain into HELO, regardless of whether it comes from Comcast or UUNet, and as long as the forged sender has a verizon.net address, and the recipient hasn't blocked VZ's silly callback system, the message is relayed. Thanks, Verizon. We can hear you now. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: Underscores in host names
on Wed, May 18, 2005 at 11:08:03AM +1000, Mark Andrews wrote: RFC 952 and RFC 1123 describe what is currently legal in hostnames. Underscore is NOT a legal character in a hostname. So, these are *all* non-compliant? Perhaps someone should tell them that. Certainly would have been nice not to get spammed by them, or to have an even easier reason to reject same. 003_150.pool-clientes.gilat.com.pe 131_202.btc-net.bg 153_199_103_66-wifi_hotspots.eng.telusmobility.com 154_ras_01.dial-ip.plugon.com.br 194_30_119_112_maca0001.lpp_za_bi.ips.sarenet.es 200.126.99.247.block7_dsl.surnet.cl 200_13_215_210.colomsat.net.co 200_63_222_138.uio.satnet.net 203_221_178_213.easynet.net.au 208_218_35_14.huntsville6.56k.cvalley.net 208_75.compnet.com.pl 212_218.bytom.compnet.com.pl 212_81_214_10_peni.gignu_adsl_ma_ma.ips.sarenet.es 229.usuarios_dhcp-195-219-18.gemytel.net 63_224_210_245.spkn.uswest.net 64_192_75_146.wcg.net 82_119_148_246.stv.ru Laubervilliers-151_12-16-191.w82-127.abo.wanadoo.fr adm_node207.ral.esu3.k12.ne.us adsl_basico_1196-170.etb.net.co adsl_lav178_218.datastream.com.mt adsl_pool_20_standard93137-133.etb.net.co adsl_pool_22_standard93139-190.etb.net.co adsl_standard_2450-46.etb.net.co c_178_237.tv-naruto.ne.jp clientes_corpor_7549-2.etb.net.co clientes_corporativos69100-82.etb.net.co corporativo_16780-201.pool.etb.net.co.80.167.65.in-addr.arpa customer125_200.grm.net d7_annex_palu_a.lac.telkom.net.id dean_rm135_2xp.business.colostate.edu dhcp-210_169_160_191.ttn.ne.jp dialup_67-36-145-125.ndemand.com dsl_61_161_30_212.turbonet.com extremo_pool_11934-63.etb.net.co extremo_pool_11943-164.etb.net.co h107_17.u.datacomsa.pl hfc3-9_32.melitaonline.net host-195_87_69_26-koc.net host-200-75-132-202.cliente_202_net-uno.net host85_14_64_224.galileusz.3s.pl host_169_253.compower.pl host_88-hra.susice-net.cz igld-83_130_117_32.inter.net.il igld-83_130_130_243.inter.net.il igld-83_130_141_197.inter.net.il ip_167_68.omni-tech.net ip_199.directservices.com maroochydore_client185.hypermax.net.au neterra139_250.neterra.net nev_dial_11.stv.ru p165_223.knu.ac.kr pc_163_209.smrw.lodz.pl pool_245224-151.etb.net.co potter_313.caasdphb.brown.edu price3_highspeed-109.preciscom.com ras56_196.un.vsnl.net.in red_200.32.64_customer_7.static.impsat.net.ve red_200.41.118_cust_17.static.impsat.net.ve sistemas__s21278-010__slv-son-001.man.newskies.net slerpool4_69121-134.etb.net.co slerpool5_69122-26.007mundo.com slerpool8_93159-211.etb.net.co sp.200_155_13_3.8x.com.br sp.200_155_9_57.datacenter1.com.br sp_200_219_192_94.datacenter1.com.br st00_162.dorm.depaul.edu sun_b035.doggy.com.au tnt_norman_int493149-194.etb.net.co tnt_pool_11979-199.etb.net.co tntcuisdnixd_169106-123.007mundo.com tntmuzuixd_169105-36.etb.net.co tv_cable_bmga7546-72.etb.net.co ubr2-5_38.onvol.net user_155_208.kutztown.edu wks_177_10.dom_bci_prod.cl ws_541a.ff.uni-lj.si -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
msu.edu abuse contact?
Could whoever is responsible for the machine at 35.11.141.251 please contact me offlist or otherwise investigate the box, which has already sent several hundred viruses to hotmail.com addresses with forged senders in my domain? I reported it yesterday to abuse/postmaster but have heard nothing back, and have received a couple hundred more bounces since. Anyone with an appropriate MSU contact they can forward this on to feel free to do so. Thanks! -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: Schneier: ISPs should bear security burden
on Sun, May 01, 2005 at 10:40:21PM -0400, Joe Maimon wrote: What does the rest of the internet gain when all IPs have boilerplate reverse DNS setup for them, especialy with all these wildly differing and wacky naming conventions? I don't care what the rest of the Internet gains, but I can say that knowing something about these wildly differing and wacky naming conventions has cut my spam load down by 98% or more. By knowing who names their networks what, even wild-assed guesses at times have kept the DDoS that is spam botnets from destroying the utility of email here. Isnt it a much simpler world where simply having rDNS lends the assumption of a supported static system as opposed to none? Bwahahaha. You mean supported static systems like: not-a-legal-address [140.113.12.106] 66.domain.tld [216.109.16.66] customer-reverse-entry.209.213.197.128 [209.213.197.128] suspended.for.aup.violation [216.41.37.5] unassigned [66.240.153.10] unassigned-64.23.24.128 [64.23.24.128] alameda.net.has.not.owned.this.ip.for.more.then.four.years [209.0.51.16] nolonger.a.customer.cancelled.for.AUPviolation [209.208.31.84] ...just to pick a few? I believe Suresh has already supplied the answer to the question of rDNS having anything to do with staticity. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: a call for peace (Re: SMTP AUTH)
on Mon, May 02, 2005 at 01:55:19PM +, Paul Vixie wrote:
in this interminable thread from hell, someone finally said the magic words:
Thankfully, there's always procmail.
and helpfully gave a specific recipe:
Yeah, but not the one you really need. Thankfully, there's always more
procmail.
it does no good for me to filter out the crackpots if the rest of you
are just going to keep on replying to same.
:0
* ^(From|To|Cc):.*av8\.com
/dev/null
It looks like Dean's Message-IDs are using 'localhost.localdomain' as a
host, so if you get mail from legitimate senders whose setups are also
broken you may not want to filter on that, too, but then again you
might. It's my understanding that Message-Id headers are supposed to
be unique in the world.
:0
* ^(References|In-Reply-To|Message-Id):.*[EMAIL PROTECTED]
* ^Sender:[EMAIL PROTECTED]
${purgatory}
HTH,
Steve
--
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: Schneier: ISPs should bear security burden
on Mon, May 02, 2005 at 01:16:40PM -0400, Joe Maimon wrote: Steven Champeon wrote: on Sun, May 01, 2005 at 10:40:21PM -0400, Joe Maimon wrote: What does the rest of the internet gain when all IPs have boilerplate reverse DNS setup for them, especialy with all these wildly differing and wacky naming conventions? I don't care what the rest of the Internet gains, but I can say that knowing something about these wildly differing and wacky naming conventions has cut my spam load down by 98% or more. By knowing who names their networks what, even wild-assed guesses at times have kept the DDoS that is spam botnets from destroying the utility of email here. Thats not quite what I was asking. Would you not have preferred being able to do all the above simply by being able to assume that all these dialup systems would not have any RDNS? No. The question restated is what is the benifit in advocating dialup names as opposed to simply recommending that dialup ranges get NO rDNS? More information is always better. For spam/abuse prevention it surely is less usefull. Its much easier to block IP with no rDNS than to maintain a list of patterns of rDNS that should be blocked. Surely. And yet, knowing that Comcast addresses are responsible for a third of the abuse against my mail server is easier when all of the hosts' rDNS ends in comcast.net, so I don't need to do whois lookups on each IP. I understand that RFCs recommend/require it. I want to know about specific benefits to the internet at large (not to the user who now has rDNS) Given a choice between ISP using unpredictable naming patterns or no name for dialup ranges, what would your preference be? Predictable naming conventions, preferably right-anchored, such as '.dialup.dynamic.example.net' If you're saying that's not possible, then I'd prefer unpredictable names over no rDNS at all (though preferably at least consistently implemented within a given rDNS domain)... -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: Schneier: ISPs should bear security burden
on Sat, Apr 30, 2005 at 07:41:34AM +0530, Suresh Ramasubramanian wrote: On 4/30/05, Steven Champeon [EMAIL PROTECTED] wrote: ANantes-106-1-5-107.w193-251.abo.wanadoo.fr You'll see 'abo' for 'cable', perhaps? as well as 'cable'. But for most abo = short for abonnement, that is, subscription / subscriber Just means its a pool of IPs assigned to users, I guess. Yes, Romain Komorn was kind enough to tell me this offlist. Thanks. Dunno. Don't have many examples of those, as I block most traffic from there, and what I didn't block didn't often have rDNS anyway. The one net.cn example I have, nova, named all of their rDNS with user.nova.net.cn - yep, that's it - what every host is named. And there's a vietnamese ISP that was clever enough to give the same rDNS - localhost - to all their IP space. Don't know which one of the three ISPs there does this, but as APNIC 20 is in Hanoi, I'll most likely find that out for myself. Yep - got a rule to block stuff from them and everyone else who does something that stupid, too. FPT Viet Nam uses 'adsl-pool-xxx', 'adsl-fix-xxx', and 'dialup-xxx' (yes, the x's are part of the actual name, not a placeholder for the numbers). So its not FPT Vietnam, but one of the two other ISPs there They may use it, too. I dunno. It's not reliable to assume that any one given network always has the same rDNS naming conventions. 'bredband'. The Japanese use 'flets' and 'ftth', the Dutch and others ftth = fiber to the home. flets is also some kind of fiber. infoweb.ne.jp uses ftth, as does solcon.nl, onsnet.nu, and a few US ISPs, such as brightohio.net, cvalley.net, and surewest.net. nmt.ne.jp uses flets, as does across.or.jp, netwave.or.jp, dsn.jp, alpha-net.ne.jp (which also apparently uses bflets, and incl.ne.jp. Google suggests others do, too, but they haven't come across my radar yet, or don't use it in rDNS naming. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: clarity
on Wed, Apr 27, 2005 at 03:19:04AM -0700, Owen DeLong wrote: Yes, most water transit companies are also the water supply company, but, in my analogy, and, in some areas, as a matter of fact, they are not the same. The chemical tampering of which you speak is done by the water supply company at the supply point before it is put in the pipes for transit to the end user. The water delivery company runs said pipes, and, my expectation from them is that they deliver what they got from the water supply company without any additional contaminants. Think of the web hoster as a water supply company. The household user is an end user. The ISP is merely a pipeline. I think the problem isn't with dirty water arriving from the water company, it's the fact that so many end users are allowing raw sewage to be poured into /other people's water/, and some ISPs don't feel compelled to do anything to save other ISPs from their users' pollutants. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
where 419 scams come from (was: Re: New IANA IPv4 allocation to AfriNIC (41/8))
on Wed, Apr 13, 2005 at 02:38:44PM -0600, Steve Meuse wrote: On 4/13/05, John Palmer [EMAIL PROTECTED] wrote: Thank you for that information. I can leave 41/8 in my router bogon list and hopefully eliminate the Nigerian 419 problem somewhat. Personally, I believe we should give them the chance to fail before we cut them off from the rest of the world. I don't think the majority of 419 email comes from addresses actually sourced in Nigeria. I can't speak to the whole world's perceptions, but for 419/aff mail seen here, the vast majority comes from IPs assigned to the following ISO country codes: (africa|AR|BF|BG|BJ|BW|CI|DK|ES|GH|IL|KE|KR|LB|LV|ML|MR|NG|NL|RW|SN|TG|ZA|ZW) Where 'africa' means IP space delegated to africa-online.com (216.104.192/20). Also see quite a bit from BR, the occasional one or two from space in the US, satellite connections, and some from FR. I know this because I use the Received: and various X-Originating-IP format headers (usually originating via some compromised or unmonitored webmail software) to extract the injection IP and reject messages if the source matches the ISO codes above in a crossref of IP to ISO code or other keyword. I used to see quite a bit from Australia, but bigpond seems to have cleaned up its act significantly. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: Time to check the rate limits on your mail servers
on Thu, Feb 03, 2005 at 04:07:10PM +0100, Raymond Dijkxhoorn wrote: The only thing I don't see is a way to remove these bots! Not everyone knows how to even look at their machines for signs of these bots. Heck, I know most of my guys here don't even know how these bots work. For a compromised system, insert CD, reinstall! ...which simply reinstalls the old vulnerabilities that made the machine suspectible to compromise in the first place. If you can't patch up from the buggy baseline in time, reinstalling from original media is often the worst thing you can do, if the machine is still connected to the network. And if the machine is NOT connected to the network, it is often not possible to get the security updates downloaded that patch the vulnerabilities. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
FW: AlterPoint Mail Security detected prohibited content in a message sent from your address (SYM:42361956180980318002)
Why content filtering is stupid: - Forwarded message from [EMAIL PROTECTED] - X-Delivered-To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: AlterPoint Mail Security detected prohibited content in a message sent from your address (SYM:42361956180980318002) Date: Wed, 12 Jan 2005 23:12:40 -0600 Subject of the message: Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet) Recipient of the message: nanog@merit.edu nanog@merit.edu - End forwarded message - -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
on Thu, Jan 13, 2005 at 12:21:04PM +0100, Stephane Bortzmeyer wrote: On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why not.) Since this list is NANOG, it is reasonable that it has a North American bias but remember the Internet is worldwide. I do not know how it is in the USA but there are many parts of the world where ISP do not have a delegation of in-addr.arpa and therefore cannot pass it to their customers. (It is also common to have many levels of ISP, so you need to go through many layers before reaching the RIR.) Seems this needs to be fixed, then. Not my problem. Requesting rDNS means I don't want to receive email from Africa. See above. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 04:51:34PM -0800, william(at)elan.net wrote: ...a very long and useful and informative message, for which I thank him. Off to go decipher the madness that is RFC3982, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 01:52:43PM +, [EMAIL PROTECTED] wrote: I think that a secure email infrastructure is a good thing to have, in and of itself. By secure, I mean one in which messages get to their destination reliably, i.e. not lost in some spam filter, and one in which a recipient can reliably know where the message came from if they feel the need to track down the sender by other means. snip In a sense, I am suggesting a similar reallocation of resources. Rather than put those resources into filtering spam, I'd suggest that we will get a better result by shifting the resources into mail relaying and managing mail peering agreements. The spam will continue but users will move to using the secure mail architecture and won't see most of it. When the spammers also shift, there will be more tools to track them down or shut them down or simply to rate limit them. OK, sounds great. Let's start by making a few SHOULDs and MAYs into MUSTs. Some of the following could be accomplished in a few hours, some are probably not fixable unless we can reallocate some of the trillions of hours we waste fighting spam to the problem AND get some political support for accomplishing them (such as fixing whois once and for all). Bear in mind that fixing email largely means fixing all the other brokenness that allows people to take advantage of email's trust model. So, then, it means fixing DNS conventions, abuse reporting support infrastructure (starting with whois), and broken mail server/client configurations. 0) for the love of God, Montresor, just block port 25 outbound already. 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why not.) Corollary: any NONlegitimate mail source SHOULD be labeled as such (e.g., 1.2.3.4.dynamic.example.net or 4.3.2.1.dhcp.resnet.foo.edu) 2) any legitimate mail source MUST HELO/EHLO with its own valid Internet hostname, not foo.local or SHIZNITSONY26354 or exchng1. Or, with their own bracketed IP. (Most do, many do not. There are very few valid reasons why not. Broken software should be fixed.) 3) any legitimate mail source MUST be in a domain with functioning abuse and postmaster mailboxes, which MUST also be listed in the whois db entry for both that domain and IP space corresponding to the mail source. (Not difficult to do at all.) 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. (NOTE: this will require fixing .org, among others whose public whois output is stale and not easily fixable via certain registrars). (Would probably take the most effort, but given a properly broad window of notification should be possible.) 5) whois data MUST be normalized and available in machine-readable form (such as a standard XML schema) - the I hate spam so I use a bogus contact addy excuse will be obsolete, as email infrastructure will be secured, right? (Honestly, how hard would this be? Gather up all the now-extremely varied formats, compromise on a superset, and map. Then put it all on a Web site or a reliable, distributed infrastructure. I'm REALLY TIRED of getting whois.$foo:111 connection refused when I'm trying to track down a spammer's support network). 6) all mail clients MUST support SMTP AUTH and the MSA port. (Many do.) All mail servers MUST support SMTP AUTH and the MSA port. (Some do.) 7) all ISPs MUST act on ANY single abuse report (including being informed of infected customer machines, which MUST be removed from the Internet ASAP. No excuses) (Halve unemployment today. Retrain textile and manufacturing workers. Outsource the entire job. I don't care. Go read broken windows theory.) 8) all mail server, antivirus, and antispam software MUST NOT accept and then bounce (to the usually forged sender) bogus warnings or DSNs. (A chicken/egg problem, really, but some systems have NO excuse - such as A/V systems that helpfully inform me that some virus that ALWAYS forges the sender did so in a message sent from a system I have no control over.) 9) all mail servers and webmail systems, etc. MUST properly include tracking information in their Received: headers. (You might be surprised how many webmail systems and large ISPs fail this one. It's largely how 419/AFF scams are propogated.) 10) all HTML display engines MUST fix the bugs that allow for a link to say, 'phish.randomisp.net.br' appear as 'wamu.com' (Social engineering, but important in this day of hostile JPG images.) That should do it. I'd also ask that HTML email simply vanish, since I'm clearly already rubbing this lamp down to its bitter metal core... ;) -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 10:32:13AM -0600, Chris Adams wrote: Once upon a time, Steven Champeon [EMAIL PROTECTED] said: 7) all ISPs MUST act on ANY single abuse report (including being informed of infected customer machines, which MUST be removed from the Internet ASAP. No excuses) One problem I have with this one is people do forge reports, and there is no way around that. Also, as long as there are networks that don't enforce source address filtering, port probing complaints cannot be validated (I take them as valid unless proven otherwise, but we have had a few that appear after the fact to be forged and/or spoofed). If you _always_ take someone off-line on a single complaint, you make it easy for someone to get someone else kicked off. Think of it as two separate requirements, one dependent on the other. 1) I'm tired of hearing stories about ISPs who let Spammer X continue because there weren't enough complaints, and 2) once you've verified that a reported infected host IS infected, take 'im offline ASAP. Or, restate it as no more abuse desk role account autoack ignorebots. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 12:55:06PM +, Eric Brunner-Williams in Portland Maine wrote: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed ... All? Even those unpublished and therefore non-resolving? Sensible for the scoped-to-totality trademarks weenies who argue that the stringspace is a venue for dilution, whether the registry publishes all of its allocations or not. Why would it matter if you deactivated an unpublished/non-resolving domain? If you care about the domain, keep the whois data up to date and accurate. I'm not sure why anyone cares about a very large class of domains in the context of SMTP however. For one thing, a very large class of domains are being used as throwaways by spammers, who use them up at a rate approaching 1 every six hours for some of them, after which they are abandoned. In the meantime, their whois info is inaccurate or (thanks, VRSN!) not yet published, anyway, so the criminals can hide behind the fact that nobody seems to care about whether whois is accurate. This destroys any potential protection value whois might offer, and allows spammers and other abusers to fly below the radar, accountable to nobody. 5) whois data MUST be normalized and available in machine-readable form There are some registries that use paper to answer registration queries. And? I'm not sure why anyone cares about a very small class of domains in the context of SMTP however. It's not a very small class of domains with more or less unpredictable data formats. It's ALL of them, or damn near. I should be able to write a program, relatively easily, that would give me any available contact or registrant information on a per-field basis, from any whois service. The wide variety and nonuniformity of the existing services makes that task daunting at best; that the information is likely wrong or stale is enough to undermine whatever faith we might have had in it once. Aggregation and reformatting have their place. We explored this in the whoisfix bofs but no working group congealed around fixing :43. What were the objections/sticking points? Again, I'm not sure why anyone cares about a very large class of whois:43 output sources in the context of SMTP however. It's not just the context of SMTP. It's the context of accountability on the Internet, which bad actors are exploiting, currently, via SMTP. I really do think it would benefit some folks here to read up on the broken windows theory of crime prevention. The majority of the 'Net is looking more and more like a warehouse full of broken windows (no, this isn't a deliberate pun on the OS) and it's no surprise that we waste many billions of dollars a year as a result. Let people get away with petty crimes, and they get the message loud and clear that you probably don't care about the big crimes, either - while giving them a great opportunity to perform those crimes in an atmosphere of an almost complete lack of accountability. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 01:49:53PM +, Eric Brunner-Williams in Portland Maine wrote: Why would it matter if you deactivated an unpublished/non-resolving domain? How do you deactivate an unpublished/non-resolving domain? You may borrow a registrar or registry hat if that is useful to answer the question. I suppose it depends on how you define 'unpublished'; and how you define 'non-resolving'. A year and a half ago, I was subjected to a joe job by Brian Westby (the bounces stopped the day after the FCC fined him), using several domains, among them adultwebpasshosting.org. It had been registered, was in whois with obviously forged data, resolved to an IP, and I reported it to ICANN for having invalid whois data. It took them, as near as I can tell (I was never notified of the action taken) at least a year to have it removed from the root dbs. I'd like to avoid going through that nonsense again. If you care about the domain, keep the whois data up to date and accurate. That is the policy articulated by the trademarks stakeholders in the ICANN drama, but how does their policy, which is indifferent to any condition but strindspace allocation, relate to any infrastructure that has one or more additional constraints? Please see my other message. Allowing domains with invalid whois data to remain in use facilitates abuse in other realms. I'm not sure why anyone cares about a very large class of domains in the context of SMTP however. For one thing, a very large class of domains are being used as throwaways by spammers ... Do you know anything about the acquisition pattern at all, or if there is any useful characterization finer in scope than all? One of the domains we host has been the victim of an ongoing joe job. The sender forges an address in the domain for the SMTP MAIL FROM: and when the message(s) bounce(s), we get the DSN(s). I've got bounce messages here going back several months. In the past month (since Dec 1), I've seen (not counting the tens of thousands of DSNs I've refused from idiot outscatter hosts): count domainreceived registered diff - --- -- --- 13 kakegawasaki.com Jan 6 2005 Dec 23 2004 14d 7 oertlika.com Jan 7 2005 no whois info n/a 6 mikejensen.info Dec 30 2004 Dec 9 2004 21d 5 kristinaficci.infoJan 8 2005 Dec 22 2004 17d 4 rhianjonesmuchos.com Jan 10 2005 no whois info n/a 4 krauszolts.info Jan 7 2005 Dec 22 2004 16d 4 gregbryant.info Dec 31 2004 Dec 9 2004 22d 4 elitke.info Dec 1 2004 Nov 28 2004 3d 3 tlepolemosmilos.com Jan 9 2004 no whois info n/a 3 latvianet.infoDec 25 2004 Dec 3 2004 22d 3 judsononly.info Dec 30 2004 Dec 12 2004 18d 2 tarumisalata.info Dec 28 2004 Dec 12 2004 16d 2 sawawer.net Dec 13 2004 no whois info n/a 2 sakkama.info Dec 15 2004 Dec 3 2004 12d 2 purkyne.info Dec 9 2004 Nov 28 2004 11d 2 kazoplace.com Dec 31 2004 no whois info n/a 2 katrianne.infoDec 1 2004 Nov 28 2004 3d 2 heinrichkayser.info Dec 30 2004 Dec 9 2004 21d 2 cavaradossi.net Dec 23 2004 no whois info n/a 2 brangane.info Jan 3 2005 Dec 18 2004 16d 1 wurmhug.com Jan 1 2005 no whois info n/a 1 ulissedinires.com Dec 24 2004 Nov 11 2004 13d 1 onlycomello.info Dec 19 2004 Dec 3 2004 16d 1 mysalpetriere.com Dec 26 2004 Dec 23 2004 3d 1 konstitutsiya.com Dec 17 2004 Dec 3 2004 14d 1 eugenisisplace.info Dec 27 2004 Dec 12 2004 15d Very few of these sighted span more than an 18 hour period between first and last appearance in a bounce. All those I've tested simply redirect to some porn site or other; for a list from November, see below: domain redirects to
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
on Wed, Jan 12, 2005 at 10:18:30AM -0800, Owen DeLong wrote: Michael, Whether you like it or not, SPAM is the problem. SPAM is a luncheon meat. UCE is one of the many problems, among the others being viruses/worms/trojans and their traffic (easily blocked by the proper upstream authority), outscatter/backscatter traffic (whether responding to joe jobs, viruses, or spammers trying to send their crud to virus-generated bogus addresses, etc.), bogus reports of forgery (cf. [EMAIL PROTECTED], for one example), C/R systems, autoresponders, callback mechanisms, et cetera. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 12:41:44PM -0600, Adi Linden wrote: 0) for the love of God, Montresor, just block port 25 outbound already. What is wrong with dedicating port 25 to server to server communication with some means of authentication (DNS?) to ensure that it is indeed a vaild mail server. Nothing at all. That's more or less what I proposed, though I'd prefer to see something TODAY, like the easily implemented rDNS fix, rather than wait any longer for SPF/DomainKeys/etc. to go through a zillion rounds of argument. As it stands, I reject a rather large percentage of the spam delivery attempts here using generic rDNS as a basis. (Either in the rDNS of the connecting host itself or in the HELO; the latter is responsible for ~75%-80% of the rejections, assumed to be almost entirely zombie-originated). Mail clients should be using port 587 to submit messages to their local MTA. Agreed. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 05:28:45PM +, Eric Brunner-Williams in Portland Maine wrote: All is too blunt a tool. So, then, when registering a domain, there should be a little checkbox saying I intend to abuse the Internet with this domain? It makes no sense to have a universal policy if it is not universally enforced. Why is it considered such a crazy proposition that domains should have valid and correct whois data associated with them? Please see my other message. Allowing domains with invalid whois data to remain in use facilitates abuse in other realms. If it isn't fixing insecure email infrastructure, then it needs to find a thread and/or list of its own. Bah. You're saying that you're uninterested in discussing the root causes that allow and even encourage abuse to occur in specific realms. I guess you're not interested in actually fixing insecure email infrastructure. The little table of domain names and redirects is slightly useful, but it would be more useful if your data could show registrar clustering. Why should this matter? Spammy can always choose a different registrar every day. So what? He is registering domains for use in abusive and criminal acts, and the message I'm getting from you is that it should only be of concern to you if he uses the same registrar? -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 04:24:42PM +, Eric Brunner-Williams in Portland Maine wrote: (quoting Anonymous): Numerous (as in at least hundreds, probably more) of spam gangs are purchasing domains and burning through them in spam runs. In many cases, there's a pattern to them; in others, if there's a pattern, it's not clear to me what it might be. From my point of view, pattern is which registars are getting the buys, for which registries, where the ns's are hosted, and for domains used in the return value side, hosting details. The latter to reduce to RIR CIDRs. I provided the IPs to which all of the latter domains resolved at the time I checked. All went to four IPs, all in China, three in the same network. The nameservers exhibit similar behavior, though often also with Brazilian nameservers along with Chinese. Not in the last month, tho: nameservers: 16 ns1.anwoo.com 202.67.231.145 HKNET-HK 14 ns1.eslom.com 61.128.196.155 CHINANET-CQ 12 ns1.epoboy.com 222.51.91.226CRTC 12 ns1.bomofo.com 221.5.250.122CNCGROUP-CQ 4 ns1.lenpo.com 207.234.224.202 AFFINITY-207-234-128-0 4 ns1.boozt.com 218.7.120.81 JINDU-COMPUTER-NET-COM 2 ns1.mynameserver.ca 202.67.231.145 HKNET-HK registrars by whois server: 15 whois.afilias.info 3 whois.planetdomain.com 2 whois.godaddy.com 2 whois.domainzoo.com 1 whois.registrationtek.com 1 whois.joker.com So? Of course .info is handled by afilias. Sponsoring registrars for .info domains mentioned upthread: 9 R126-LRMS - Enom 4 R239-LRMS - Primus 2 R171-LRMS - GoDaddy There's your clustering. Feel free to somehow reduce these to CIDRs or ASNs; they're not used in the message headers anyway, so all you can do is block the redirection for your users, but not prevent them from being deluged with the spam itself, nor prevent me and others from being deluged with the bogus DSNs. So what? Eventually, better antispam techniques will lead to the ability to block messages from or referencing domains with banned nameservers. And then spammy will set things up so that he has a new nameserver for every run. And we'll still have insecure email, because he'll have continued to get away with it, because he can hide behind private whois for his domains registrations, he'll continue to burn through the net namespace leaving nothing but scorched earth, and none of the underlying conditions will have been addressed. It's no longer a simple matter of blocking the sender origin, botnets have taken care of that. It's no longer a matter of blocking known spammy domains in SMTP envelopes; they're forging them. It's not a matter of blocking mail with known spammy domains in it, as these are one-a-day throwaway redirectors. It's not a matter of blocking mail with domains that point to rogue nameservers, ASNs, or CIDRs, spammy can register new domains and use new ones every day. It's not a matter of any of these things, though I use them all, and with some effect. The problem is that spammy is getting away with this by modifying his tactics slightly and keeping a step ahead of the game, and because few understand or care about actually /fixing the underlying brokenness/ that lets him get away with it day after day. There is more, but that is the first cut, localization of registrar(s) and registries and CIDRs. I fail to see how isolating registrations to a single registrar changes the facts on the ground - if anything, you're already showing that you are at least one step behind Spammy, by making this a requirement. Or, alternately, you're simply saying that those who care about net abuse are shackled by ICANN's bylaws and therefore we can do nothing. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
fixing the underlying causes of network abuse (was: Re: fixing insecure email infrastructure (etc.))
on Wed, Jan 12, 2005 at 07:49:59PM +, Eric Brunner-Williams in Portland Maine wrote: snip Thus far, all you've done is recycle the policy claim of the trademarks interests, a highly effective stakeholder and rational entity within ICANN, and the policy claim of the law enforcement interests, [...] I'm sorry, but I'm not following. By asking for domain registrations to be transparent and monitored for accuracy, I'm echoing the policy claim of everyone who has ever tried to determine the registrant of a domain and found it to be laughably forged, incorrect, out of date, or protected by some other entity whose primary purpose seems to be to help spammers hide. Whether this group of interested parties includes the trademarks interests is irrelevant. This thread however is about SMTP, and some glop that might make it differently, or less insecure. Clearly we need to change the Subject: then, as you seem bent on ignoring my statements about the underlying causes of net abuse via email with this dodge, and it's getting tiresome. Do you want to see whois records normalized and monitored for forgeries? Do you believe this could have an effect on the ability of spammers and others to abuse network resources? -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote: On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide. Yes, but he asked for a rDNS solution specifically... I think Steve was referring to some things that can be implemented right away, like if you operate a mailserver, please make sure that it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com, try to give it unique and non generic rDNS, preferably with a hostname that starts off with smtp-out, mail, mta etc) Yep. And it helps if the rDNS is right-anchored, (uses subdomains to distinguish between various assignment types and technologies) a la 1-2-3-4.dialup.dyn.example.net 4-3-2-1.dsl.static.example.net ^^^ as opposed to dyn-dialup-1-2-3-4.example.net static-dsl-4-3-2-1.example.net as the former is easier to block using even the simplest of antispam heuristics. I'd love to see a convention, or even a standard, arise for rDNS naming of legit mail servers. But I'll happily settle for decent and consistent rDNS naming of everything else ;) Basically a call to operators to adopt a consistent forward and reverse DNS naming pattern for their mailservers, static IP netblocks, dynamic IP netblocks etc. ...and to ISPs to facilitate the process by supporting their users who want to run mail servers, and helping the rest of us use such techniques to quarantine the spew from zombies and less conscientious mail admins. I'm always willing to be educated on why it is impossible for any given ISP to maintain an in-addr.arpa zone with PTRs for their customers who wish to be treated like real admins, as opposed to casual consumer-grade users with dynamically assigned addresses. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: verizon.net and other email grief
on Fri, Dec 10, 2004 at 12:36:12PM -0800, william(at)elan.net wrote: On Fri, 10 Dec 2004, Rich Kulawiec wrote: Verizon has put in place an exceedingly stupid anti-spam system which does not work, which facilitates DoS attacks, and which provides active assistance to spammers. The technique discussed is called callback verification and I do not agree that the technique stupid or provides assistance to spammers. I do agree that some of the aspects in how this was implemented by Verizon is not correct and causing problems. snip But for current situation it does work just fine and causes number of emails with randomly generated emails to be stopped. Erm. Yeah, it stops them from being delivered to Verizon by shifting half the cost of verification onto the victims. , and (b) it doesn't scale. The scalability depends on implementation. Since we have Verizon implementing it, I'm guessing it scales just fine based on the size of their email network. See above. It doesn't scale when /everyone else/ starts doing it. Callback verification if properly implemented will never generate more junk SMTP traffic as DATA part of SMTP transmission never happens. By the time Verizon's callback servers hang up on us they've already generated more junk SMTP traffic, wasted our resources to protect their customers, and aided spammers doing list validation. Your claim that dictionary attacks are always alphabetical is pretty weak and brings nothing to bear on the actual problem - that by rejecting mail from a given address because of (possibly spurious) verification, they are actually giving the spammers a tool they can use to cull bad addresses from their own lists. The only positive thing I have to say about Verizon's callback scheme is that so far it has not been seen here more than 6 times in a single day in the past two months. So they must be doing some caching, given that at least one of the domains we host has been under joe job outscatter attack for several months running now. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: How many backbones here are filtering the makelovenotspam scr eensaver site?
on Thu, Dec 02, 2004 at 02:56:29PM -0500, Hannigan, Martin wrote: Possibly. What will happen if the Lycos botnet gets hijacked? The conversations between the clients and the servers don't appear to be keyed. If a million clients got owned, it would be the equivalent of an electronic Bubonic Plague with no antidote. You mean, like the existing botnets we already know exist but are already under the control of spammers? What's the difference? Why is everyone so upset about Lycos and nobody seems to be doing much of anything about the /existing botnets/, which conservative estimates[1] already put at anywhere from 1-3K per botnet to upwards of 1-5M hosts total[2]? Steve [1] http://newpaper.asia1.com.sg/top/story/0,4136,67698-1,00.html There may be millions of such PCs around and they can be rented for as little as US$100 ($176)-per-hour. http://www.messagelabs.com/emailthreats/intelligence/reports/monthlies/October04/default.asp Some estimates have suggested a botnet in excess of tens of thousands of computers. [per virus outbreak] http://www.usatoday.com/tech/news/computersecurity/2004-07-07-zombie-pimps_x.htm Small groups of young people creating a resource out of a 10-30,000-strong computer network are renting them out to anybody who has the money, a source in Scotland Yard's computer crime unit told Reuters. http://www.sans.org/newsletters/newsbites/newsbites.php?vol=6issue=43#315 CipherTrust recently published research claiming that all phishing attacks on the Internet are conducted with the use of one of five zombie networks, or botnets. Each botnet comprises roughly 1,000 PCs. In addition, the research shows that 70% of zombie PCs are also used to send spam. http://news.zdnet.co.uk/internet/security/0,39020375,39167561,00.htm Linford said that every week more than 100,000 PCs are recruited into botnets without the owner's knowledge. A botnet is a collection of -- usually -- Windows-based PCs that have been stealthily taken over by malware. Users have no idea that their computer has been corrupted. [2] the CBL, for example, currently lists 1.1M, and (here, anyway) only blocks around 15-25% of our incoming spam. I've seen round robin attacks of upwards of fifty bots at a time (same timeframe, sender, and target, from multiple hosts in multiple countries/ISPs/networks) whereas suspected zombies account for 35-45% of all inbound spam delivery attempts here. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: How many backbones here are filtering the makelovenotspam scr eensaver site?
on Thu, Dec 02, 2004 at 12:55:02PM -0800, Chad Skidmore wrote: quoting me: What's the difference? Why is everyone so upset about Lycos and nobody seems to be doing much of anything about the /existing botnets/, which conservative estimates[1] already put at anywhere from 1-3K per botnet to upwards of 1-5M hosts total[2]? Well, the primary difference is that Lycos is trying to market what they are doing as a good thing in a fairly public manner. If their vigilante efforts become accepted as OK then it further opens the door for others to take the next step towards making dDOS attacks ok as long as you feel your motivations are pure. As network operators we all need to make sure that we enforce our AUPs and make it known that breaking those AUPs is not ok just because you feel your motives are pure. Most AUPs have some language that basically states that dDOS and simlar activities are bad and we will take action if you engage in said bad activities. My point was to Martin's question about what would happen if - god forbid - there were large botnets under the control of spammers; a careful reading will suggest that my major point was, duh, that there already are large botnets under the control of spammers. To your other point, how do you know that other botnets are not being identified and taken down every day by network operators? I know for a fact that they are, they just are not nearly as public as this one so those activities go largely unacknowledged. Good point. Simply put, I can (and do) read my own mail server logs. And I can see that many ISPs - regardless of what they may be doing in onesy-twosy increments - simply aren't doing enough to prevent new botnet infections from wasting my server's cycles in futile attempts to deliver spam, outscatter, virus warnings, etc. etc. ad infinitum. This costs me time and money, and many of the same ISPs mentioned above are simply cost-shifting their own responsibility onto me and everyone else, and I'm tired of it. Not to say there aren't responsible ISPs, and I hope that anyone who /is/ a part of the solution, rather than the fertile substrate for the problem, is capable of recognizing that and not taking offense when I point out there are others who could do more. As for go180.net, you don't show up much on my radar, but on Nov 9th we were hit by a spammer from SpokaneHotZone-63.go180.net [66.225.5.63]. I trust this is not a legitimate mail server and I can block it and any other host that looks like it within the same domain, right? Thanks. Otherwise, you may want to do something to distinguish it from the other generic hosts in the same range. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: How many backbones here are filtering the makelovenotspam scr eensaver site?
on Thu, Dec 02, 2004 at 08:58:03PM +, Christopher L. Morrow wrote: On Thu, 2 Dec 2004, Steven Champeon wrote: on Thu, Dec 02, 2004 at 02:56:29PM -0500, Hannigan, Martin wrote: Possibly. What will happen if the Lycos botnet gets hijacked? The conversations between the clients and the servers don't appear to be keyed. If a million clients got owned, it would be the equivalent of an electronic Bubonic Plague with no antidote. You mean, like the existing botnets we already know exist but are already under the control of spammers? What's the difference? Why is everyone so upset about Lycos and nobody seems to be doing much of anything about the /existing botnets/, which conservative estimates[1] already put at anywhere from 1-3K per botnet to upwards of 1-5M hosts total[2]? perhaps the difference is 'reponsible people' don't go out and recruit botnets... Lycos, as a corporate entity with it's business model dependent upon the health and wellbeing of the Internet would try to be 'responsible', or so I would have thought. I agree. I also think it's up to the companies providing the Internet connectivity to the non-Lycos-owned botnets to prevent such activity from affecting others. arguing that there are murderers and rapists out there and that 'nothing is being done' is hardly reason to become one yourself. I couldn't agree more that vigilantism isn't the answer. My earlier remarks were directed to the shock and awe evident in the possibility that - via Lycos - there might be, heaven forbid, /large numbers of computers under the control of spammers, that could be used in spamming and abuse/. All I was pointing out was that, surprise, surprise, there already are. So why anyone thinks Lycos' botnet being hacked is /any different/ from /the current situation/ is utterly beyond my ken. Why would any spammer bother to hack Lycos' botnet? They /already have their own/. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: How many backbones here are filtering the makelovenotspam scr eensaver site?
on Thu, Dec 02, 2004 at 04:15:34PM -0500, Hannigan, Martin wrote: quoting me: My point was to Martin's question about what would happen if - god forbid - there were large botnets under the control of spammers; a careful reading will suggest that my major point was, duh, that there already are large botnets under the control of spammers. Um, not 1 million bots - in concert. And you know this how, exactly? I'm sure not convinced. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: How many backbones here are filtering the makelovenotspam scr eensaver site?
on Thu, Dec 02, 2004 at 04:18:52PM -0500, Hannigan, Martin wrote: Can you direct me toward a singluar entity of 1MM bots controlled by a single master? No, I cannot. I *can*, and have, forward on reports by those more in the know than I that estimate 100K new bots / day are being added, and I can certainly point to incidents here which suggest that the problem is widespread, that the spammers responsible are few, and that many ISPs continue to refuse to contain the problem. Do the math. 100K / day new bots, added by a few responsible parties, and it's not hard to see that over a brief period of time any one of those parties might control over a million hosts or more. I think you might be behind on what's going on in botland lately. By all means, enlighten me. All I see from my limited pov is that bots are useless if disallowed from sending spam via port 25 outbound, and that every day sees hundreds if not thousands, of new bots trying to send spam to my users, which suggests that /nothing is being done to prevent them from using the available resources/. Convince me otherwise, please. I'm all ears. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: How many backbones here are filtering the makelovenotspam scr eensaver site?
on Thu, Dec 02, 2004 at 04:46:00PM -0500, Hannigan, Martin wrote: quoting me: Um, not 1 million bots - in concert. And you know this how, exactly? I'm sure not convinced. http://w3.cambridge-news.co.uk/business/story.asp?StoryID=65877 Lycos Europe's 20 million users will all be invited to download the software, but it is available to anyone with an internet connection running either Windows or Mac OSX or Mac OS9 operating systems. http://edition.cnn.com/2004/TECH/internet/12/02/anti.spamvigi.ap/ Around 65,000 people already signed up for the offensive, called Make Love not Spam before Tuesday's official launch on a website by the same name, the company said. It is urging its 22 million users to download the screen-saver, but says anyone with a computer is welcome to it. Yes, yes - I know that Lycos has tens of thousands. What I want to know is how you know that there aren't existing 1M bot zombie nets aside from the Lycos attempt (which as you can see, is thus far only comparable to the 100K/day estimate given by Steve Linford). -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: is reverse dns required? (policy question)
on Wed, Dec 01, 2004 at 02:41:00PM -0500, [EMAIL PROTECTED] wrote:
On Wed, 01 Dec 2004 13:16:49 EST, Steven Champeon said:
FWIW, 40% or more of the inbound spam mail here comes from hosts with a
generic rDNS naming convention (even after DNSBLs and other obvious
forgery checks such as hosts using my domain(s)/IP(s) in HELO/EHLO). We
simply quarantine any mail from hosts without rDNS at all, and reject
all mail from non-whitelisted generic hosts.
Any issues with dealing with the distinction between (for instance)
FOO.generic.BAR.(com|net|org) (where generic is the 3rd level) and
FOO.generic.BAR.co.uk (where it's a level further down)? Similarly, do you
just treat all of *.info or *.biz as a generic swamp? Any other TLD-related
issues you've identified in counting up that 40%?
Well, for various reasons I maintain a database of some ~7K or so naming
conventions and run my matches against all of them (using a TLD-based
right-to-left sort, but still, I know it can be done more efficiently).
The practice stems from the days (5/03) when I'd only mapped some 1500 or
so conventions.
The access.db checks are done right-to-left, too, so
Connect:dhcp.vt.edu ERROR:5.7.1:550 go away, dynamic user
Wouldn't catch 1.2.3.4.dhcp.vt.edu.example.com anyway.
All of my matches are currently done on the whole rDNS hostname string,
not on a subset, though I'm moving towards a left-anchored subset as it
cuts my live pats down from ~7K to ~3200 or so. (e.g., refusing mail from
hosts with names like ^h[0-f]{8}\. instead of checking all of the pats
that start with h[0-f]{8}). I've got a list of the most common 100 or so
left-anchored pat subsets, and hope to put them into practice here soon.
So I may have more feedback then.
I don't simply treat info/biz as a swamp in practice, no - despite the
fact that they're obviously pretty well flooded and swarming :/
So, no TLD-related issues of the sort you seem interested in.
--
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: EFF whitepaper
on Mon, Nov 15, 2004 at 04:45:24AM +, Paul Vixie wrote: [EMAIL PROTECTED] (Sean Donelan) writes: http://www.eff.org/wp/?f=SpamCollateralDamage.html excerpt: I. The Problem MoveOn.org is a politically progressive organization that engages in online activism. For the most part, its work consists of sending out action alerts to its members via email lists. Often, these alerts will ask subscribers to send letters to their representatives about time-sensitive issues, or provide details about upcoming political events. Although people on the MoveOn.org email lists have specifically requested to receive these alerts, many large ISPs regularly block them because they assume bulk email is spam. [...] i reject all mail from moveon.org here. not because i assume bulk e-mail is spam, but because i still personally receive all mail sent to any address at cix.net, and quite a few people who wish to subscribe from cox.net end up typing cix.net by mistake. (i and o are adjacent in QWERTYland.) i'm therefore in a position to prove that moveon.org does not verify the ownership or permission status of new e-mail addresses before sending political information. i tried complaining, but moveon.org's postmaster function appeared to be understaffed or overworked or both. I couldn't agree more. We have several users here who signed up for the moveon.org mailings back when the group was a single-issue activism project (getting the US to move on and stop wasting its time trying to impeach Clinton). None of them expected to become permanent members of what soon became a shrill, extremely partisan, and spam-spewing group. To the best of my knowledge, no attempt to unsubscribe has been respected. That said, I've long since stopped listening (or contributing) to the EFF as I see their war on antispammers as counterproductive. John Gilmore runs a well-known open relay at toad.com, and for some reason thinks that free, anonymous speech is important enough to let spammers drown it out through sheer volume. I prefer having usable email, so I no longer support the EFF. -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: EFF whitepaper
on Mon, Nov 15, 2004 at 01:06:09PM -0800, Tom (UnitedLayer) wrote: On Mon, 15 Nov 2004, Steven Champeon wrote: John Gilmore runs a well-known open relay at toad.com, and for some reason thinks that free, anonymous speech is important enough to let spammers drown it out through sheer volume. Someone famous said something about paying a high price for free speech, I think this perhaps would fall under that category. I know - I too, pay a high price to maintain my own mail servers. Mr Gilmore spends quite a bit of time tending to his mail server to ensure that spammers do not abuse it. Congrats. So do I. Any spammer who spends time pumping mail through his server is going to realize quite quickly that its not worth their time. Its a very old slow machine on a T1 with other intentional slowdowns added to the MTA, and some amount of spam filtering. I would say it would have a hard time passing more than 1 message a minute. Great. And this affects those of us with not-so-old, not-so-slow machines how? The bottom line is that Gilmore, and the EFF, have taken a very soft stance on spam, believing it to be less important than free speech or anonymous speech. Oh, well. I believe that the EFF already has all the support it needs, and so I don't contribute to their efforts to make my life more difficult. I would think that most spammers would give up and go abuse an open proxy somewhere, they're much more plentiful and less cluefully tended. Oh, probably. Or one of the million-host proxy botnets. Or another open proxy. Or another open relay. Or a hacked webmail server, etc. etc. etc. The existence of other more preferable alternatives doesn't obviate the fact that the EFF has not been tough enough on spam. http://www.eff.org/Spam_cybersquatting_abuse/Spam/position_on_junk_email.php Wow. So, no antispam measure with any possibility of blocking legitimate mail should be adopted. In other words, we should just go back to 1993? http://eff.org/wp/?f=SpamCollateralDamage.html Wow. So, any collateral damage is unacceptable? Even when the source of the so-called legitimate mail is a spammer, pure and simple, with bad ideas about what constitutes mailing list management? Granted, they're working with others to define things that most of us have known about for years. Gee, thanks, guys. Why not spend some time using the best practices already written up? Hell, does the EFF even do subscription confirmations yet? Or do they assume that anyone capable of filling out a Web form is incapable of lying or mistyping their email address? RFC2505 is five years old and a BCP now. Its first admonition is to put an end to unauthorized relaying. Second is to provide trace information in Received: headers. Oops! Both essentially outlaw anonymous speech via email. In a nutshell, email requires accountability. The EFF apparently thinks that is too high a price to ask for email. -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: EFF whitepaper
on Mon, Nov 15, 2004 at 02:47:14PM -0800, Tom (UnitedLayer) wrote: On Mon, 15 Nov 2004, Steven Champeon wrote: And this affects those of us with not-so-old, not-so-slow machines how? By the fact that there is no way in hell that he could relay a large amount of spam... You seem to be confusing the single instance with the widespread application of the policy. My problem is with the latter, which is what the EFF is pledged to defend in the face of widespread damage to the medium they hope to save thereby. Put simply, I'm fine with a few well-known anonymizing mail servers. I also reserve the right to reject mail from them. I am not fine with an organization pledged to defend the principle for /all mail servers and spam sources/ regardless of whether they are under the control of spammers (and with no mind paid to the fact that a great deal of spam is sent via compromised machines that are unlikely to be used by freedom fighters or whistleblowers, etc.) Come on - do you really think the Russian mafia is going to allow free use of their botnets so that Chechnian freedom fighters can post propaganda? I don't. Not even if they were paid for it. The bottom line is that Gilmore, and the EFF, have taken a very soft stance on spam, believing it to be less important than free speech or anonymous speech. By definition, the EFF's main concern is free speech and privacy. And I have supported them in the past for exactly their dedication to that concern. However, they now confuse government censorship on the one hand, with the abuses of a system by fraudsters and others (often in league with the very same countries whose censoring governments the EFF opposes) on the other. Alan Ralsky hosts his servers in China. Do you really think that the goal of protecting freedom is served by encouraging everyone not to reject mail from those servers? Given that China's rDNS is so hosed or nonexistent as to make local, automated judgements difficult to impossible, it's far easier for those of us who don't want Ralsky's junk to simply reject all mail from China. If China doesn't like it, they should reconsider hosting Ralsky. The same goes for any country or ISP hosting or enabling spammers. And yes, I know that's a broad brush, and may not be appropriate for everyone. That's my whole point - that by ceding the spam battle over a misguided idea of protecting free speech, the EFF is actually encouraging others to paint with similarly broad brushes in their own defense - and undermining their own intentions. I didn't make the decision to allow 419/AFFers to post through Tiscali's webmail servers - Tiscali did, and they continue to let the abuses occur. Bigpond has largely fixed their 419/AFF problem, by disallowing use of their webmail accounts to non-AU users (in the process, they also broke their Received: header trace information, but hey). Got a problem with their policy? I don't. I had a user here who got upwards of 100/day - nearly all 419/AFF spam. Much of that has disappeared, thanks to the implementation here of policies that others were incapable of making, in order to deal with /their/ abuse problem, not mine. Privacy is a great goal. In my mind, it has its price. If I want to vote to protect my privacy, I register. If I want to drive a car, I get a license and get insured, and can prove it in case I run into someone else. If you want to be on the Internet, I damn well better be able to contact you (or someone who has taken responsibility for your presence here) in the event that you run dictionary attacks against my mail server, or try to send a million spam messages through your broadband channel, or run a worthless and buggy OS without a firewall and thereby let yourself get owned by anyone and become a vector for abuse. Barring that, I'll just block you and anyone who looks like you, and call it a day, and selectively unblock or whitelist once you've met my policy criteria. Those who prattle on about rights forget about their corresponding responsibilities, and undermine their very case by appearing to lack any sense of the price we pay for the former through the latter. http://eff.org/wp/?f=SpamCollateralDamage.html Wow. So, any collateral damage is unacceptable? To me, and people who rely on email for reliable communication, yes absolutely. Collateral damage is unacceptable, period. Then it would behoove you to support efforts to make email accountable rather than decry such attempts as censorship. Lacking other solutions to the spam problem, everyone tries their own. Which is more important? That we can all get behind industry-wide proposals, or that we all uniquely splinter useful protocols due to our own necessities, dictated by the demands of real usage? I'd love to stop wasting time chasing the rats out of my mail server. Until then, I am doing what I can to analyze inbound spam and adjust my policies accordingly to keep it out. Rather than fight for the rights
Re: Okay, I'm just going to _assume_...
on Thu, Oct 21, 2004 at 09:19:11PM -0700, Bill Woodcock wrote: ...that there's some operational content somewhere in here: http://www.cisco.com/edu/peterpacket/ ...though I'm on kind of a slow link, so I'm still looking. My eternal thanks to Suresh for finding this. My day is complete. What's a villian? And why does everyone have such incredibly white teeth? -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: BCP38 making it work, solving problems
on Wed, Oct 13, 2004 at 07:09:10AM +0530, Suresh Ramasubramanian wrote: [EMAIL PROTECTED] [12/10/04 13:16 -0400]: If I, and my little 7-man company, can afford to have me solve the problem on our end, why the heck can't you do the same? You can do it because you are a 7-man company. So can I. However, companies the size of Sprint cannot do it. Most filtering that I've seen (email, router, whatever) that just works great for a 7 man company will not work when you serve several million users, that's a fact. A 7 man Web app development company with ~100 or so hosted POP mail accounts, FYI. Not that it matters. If I can write rules that block spam with forged headers, so can any damn body else. And I'm tired of getting the bounces from those who feel it's not possible. Some examples of headers from mail that other ISPs have felt compelled by their size to accept and then bounce back to me: Received: from dslam129-213-59-62.adsl.zonnet.nl (62.59.213.129) by 0 with SMTP; 27 Aug 2004 21:20:16 - Received: from thewordfactory.com (mail.thewordfactory.com [216.27.21.211]) by dslam129-213-59-62.adsl.zonnet.nl (Postfix) with ESMTP id 0453B70AB1 for [EMAIL PROTECTED]; Fri, 27 Aug 2004 15:29:58 -0500 The second Received header is forged. The first is from a dynamic DSL line. The message was accepted by mail.philonline.com ([203.177.71.7]) and bounced back to me in a message that didn't even have a Message-ID header, letting me know they are so dumb they accept forged mail from dynamic IPs and only then analyze it to see if the user exists or if the forged sender should be notified. Received: from ip84-RND_DIGIT[2-3]-RND_DIGIT[2-3]-RND_DIGIT[2-3].4tvMsWC8okzw.customer.aviamail.zzn.com (50-RND_DIGIT[2-3]-RND_DIGIT[2-3]-RND_DIGIT[2-3].customer.aviamail.zzn.com [24.135.29.42]) by ezEG4GA1.aviamail.zzn.com (RND_DIGIT[1-3].RND_DIGIT[1-3].RND_DIGIT[1-3]/RND_DIGIT[1-3].RND_DIGIT[1-3].RND_DIGIT[1-3]) with SMTP id B3tc6UKcaTVY This was in a bounce from mail.cygentech.com (geoanalysis36.cust.viawest.net [216.150.205.36]). We've been seeing these headers for more than a year now, and blocking them almost as long. But these idiots can't see that backscattering them at me is rather stupid. Just a few of the others who've done this (accepted mail with completely bogus RNDizer headers from broken spamware): plesk4.merkury.com (216-86-139-44.tns.net [216.86.139.44] (may be forged)) smtp03.adnc.com (smtp03.adnc.com [206.251.248.23]) cobble.phpwebhosting.com (cobble.phpwebhosting.com [64.65.61.211]) date.marketorder.com ([64.65.150.229]) (by way of postini) exchgkom.TRI.NET (mail.tecolote.com [65.170.33.20]) DNS2.TCBINC.NET (DNS2.TCBINC.NET [64.124.116.30]) mail-in-01.netsonic.net (mail-in-01.netsonic.net [66.180.172.253]) ms1.tcnoc.com (ms1.tcnoc.com [63.150.10.30]) exchange3.corp.bcs-tx.com (ip204.bcs-tx.com [216.136.93.204] (may be forged)) [...etc...] My full list of backscatter hosts is ~17K entries long. And those are just the ones who've hit my servers. Never mind the charter/rr/att/hotmail/etc. hosts that are also listed - I'm not just talking about random Exchange boxes here - I'm talking about every major ISP with which I am familiar. Want to know if you're responsible for backscatter abuse? Just ask. As you know, Suresh, Outblaze does the same thing. Listed here as hosts we no longer accept null sender mail from: mta1-1.us4.outblaze.com BOUNCER spf0.us4.outblaze.com BOUNCER spf10.us4.outblaze.com BOUNCER spf1.us4.outblaze.com BOUNCER spf2.us4.outblaze.com BOUNCER spf4-1.us4.outblaze.com BOUNCER spf5-1.us4.outblaze.com BOUNCER spf7-17.us4.outblaze.comBOUNCER At least you've said you're moving towards fixing it. Thanks. One false positive report per week from 7 users. How many per week - or per day - when you have 40 million users, is a question that gets answered real fast. I don't even want to go into the backscatter messages that show that: - the sender forged the IP/domain of the recipient into HELO/EHLO - the recipient accepts mail for unknown accounts - the relaying host forwarded Webmail from Nigeria without proper Received headers added for blocking purposes - you name the obvious spamsign Come on, there is so much obvious crud that should be checked that isn't being checked - we could reduce backscatter by a third or more simply by refusing during SMTP handshake messages from hosts that forge the receipient IP/hostname/domain in HELO, or to users that don't exist, or if virus filters were clueful enough to drop, rather than emit DSNs, for known virus-originated messages that always forge the sender. A lot of the bad filtering (or lack of filtering, for that matter) decisions I've seen at large network providers and ISPs is generally where they are also unresponsive to their users and to the internet community that reports stuff to them (quite a few places I could name where most role accounts seem to funnel straight
Re: FW: The worst abuse e-mail ever, sverige.net
on Thu, Sep 23, 2004 at 10:37:10AM +0200, Lars-Johan Liman wrote: [EMAIL PROTECTED]: Congrats. Ask your ISP for non-generic rDNS, in your domain, so I know where to send the abuse reports. I did. Reverse *what*? So explain it to them in words of two syllables or less, where possible. I recommend using I am finding a new eye ess pee. Because that's how things are today. You're a 1-in-50-million chance, as far as I can tell from my mail server. With that attitude you're never going to improve things ... /My/ attitude? You're the one giving your money to a bunch of incompetents. -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: FW: The worst abuse e-mail ever, sverige.net
on Wed, Sep 22, 2004 at 10:16:41AM +0200, Lars-Johan Liman wrote: I cannot agree to the block port 25 line of action. I am a Unix sysadmin, with 15 years of experience as sendmail and DNS expert. I have a DSL line at home, with static IP, and generic rDNS provided by my ISP. Behind it I have a serious Unix server, configured to roughly the same standard that I use at work. Congrats. Ask your ISP for non-generic rDNS, in your domain, so I know where to send the abuse reports. I know enough about this business to not trust my ISP with anything more than moving packets to and from my server (and even that is streching it ;-). I don't want to pay for their lousy mail service, I can do it better myself. And you don't want to let me? I don't mind at all. Get rDNS that provides a clue that you have a clue, and I'm happy as all get out to accept mail from you. Otherwise, you're functionally identical to fifty million spam zombies, as far as I have time to determine. Understand me? You're the /rare exception/. Now, *why* should *I* be punished because the rest of my neighbours have chosen to jump into the commercial bed of an operating system that is a walking invitation to cracking? Because that's how things are today. You're a 1-in-50-million chance, as far as I can tell from my mail server. snip unhelpful Internet architecture lesson -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: The worst abuse e-mail ever, sverige.net
on Tue, Sep 21, 2004 at 10:16:52AM -0600, james edwards wrote: This is the rudest, most arrogant abuse complaint I have seen. It is a frigging dial up user. I'm confused. Your user on 65.19.17.201 - a dialup user, probably running an infected Windows box, sent spam to the complainant, who figured out who to complain to, explained in great detail (and in English) that well, it shouldn't have happened if you'd had any clue whatsoever, and had blocked outbound port 25 connections from your own users (or at the very least those users of yours who are listed in DNSBLs for spamming or relaying!) and you think he's being /arrogant/? Christ, I'd say he's being helpful. Get over yourself and /fix your own network/. Deal with the frigging complaint, and STFU. I already waste /way/ too much time dealing with equally stupid and/or lazy network/mail admins who won't frigging fix their own networks, and doesn't blame the complainant one frigging bit. Currently, I'm dealing with the backscatter bounces from three concurrent joe jobs, sent by such laughably broken spamware that I'm /amazed/ any of it was accepted in the first place, much less accepted and /then backscattered to me, the victim/ because of still more misconfigured/idiotic antivirus stupidity. Sheesh. Get over /yourself/. Your network is rude by its very existence, if it lets spammers relay crud by way of it. Your own arrogance in thinking it's not your problem to fix is astounding. Please don't bother to reply; it will take time away from fixing your network. Steve -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: The worst abuse e-mail ever, sverige.net
on Tue, Sep 21, 2004 at 11:00:53AM -0600, james edwards wrote: Sheesh. Get over /yourself/. Your network is rude by its very existence, if it lets spammers relay crud by way of it. Your own arrogance in thinking it's not your problem to fix is astounding. I did no say it is not my problem, we have a 10 year history of being very pro-active for all abuse issues and have a dedicated staff person to deal with these issues. OK, then, perhaps you can explain why I have received backscatter from web.cybermesa.com [65.19.6.7] or why even though I got spam from sf-du170.cybermesa.com [209.12.75.170] back in October 2001, and from sf-du201.cybermesa.com [209.12.75.201] in February 2002, you still haven't blocked outbound port 25 traffic from those obviously vulnerable hosts? http://groups.google.com/groups?num=50hl=enlr=ie=UTF-8newwindow=1safe=offc2coff=1q=group%3Anews.admin.net-abuse.*+cybermesa.combtnG=Search Looks like you've got an ongoing problem with those dialup ranges. Slaming my mail admin because a dial up user has a virus is rude, period. Nope. Sorry. Emitting spam/viruses or backscatter even though you know you (or your users) have a problem, expecting everyone else to block your network, and whining when someone has the gall to call you on it - that's rude. Of course, it's pretty common, but that doesn't make it any less rude. Our dial up address space is listed, if people choose to block mail from that space. I'm curious - where is it listed? I don't see anything on your Web site that even suggests a place to go looking for abuse/helpdesk/support info. Much less a banner inviting more responsible mail admins to block your listed netblocks Will a regex of [a-z]+[0-9]*\-du[0-9]+\.cybermesa\.com block all of your dialup ranges by rDNS? What about your DSL and ISDN ranges? How are they named? Consistently, I hope. And of course I also hope they resolve back-and-forwards to the IP, so spam/viruses don't squeak through sendmail due to being possibly forged. Why aren't they named so that sendmail and other MTAs can block your dynamic ranges by RHS in access.db, instead of having to use regexes? Hint: blah-1-2.dynamic.cybermesa.com or blah-3.4.dialup.cybermesa.com or foo-5-6-7-8.dsl.cybermesa.com makes this much less annoying and difficult, and conveys the same information as sf-du120.cybermesa.com. I apologize if I offended you personally, I intended to do it professioanlly. Steve -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: FW: The worst abuse e-mail ever, sverige.net
on Tue, Sep 21, 2004 at 02:11:11PM -0400, Daniel Senie wrote: snip good info 2) for dialup, DSL and Cable users on dynamic ports who should not generally be running servers, name the INADDR with something like: w-x-y-z.dialup.example.net w-x-y-z.dynamic.example.net or similar. I don't care what scheme you want to use to the LEFT of 'dialup.example.com' or 'dynamic.example.com' but please put the information about these being dynamic blocks in a place where they can be filtered using simple mechanisms (i.e. without regex overheads). With the naming above, it's easy to filter out dialup.example.com in the access lists of mail servers without any worries. Users coming in from those addresses using authenticated connections to the submission port will work fine, while spam direct from those machines will not work. Many ISPs do this quite well. While it's still some work for the receiving systems vs. port 25 filtering, it sure beats guessing about remote topologies. FYI - I've been tracking rDNS naming conventions for many ISPs for the past year and a half. (Basically, if your network is secure, I don't know about you - I only track rDNS for hosts that relay spam or spew viruses at me). Of the approximately 4800 networks (by domain) I've tracked, 1935 are known to be in the US, Mexico, or Canada. Of those, 509 have some form of RHS-friendly rDNS. Roughly 26%. Better than last year, but still pretty bad. cgocable.ca cabletv.on.ca aci.on.ca eastlink.ca powergate.caprimus.ca sympatico.caubc.ca uoguelph.ca uniserve.ca utoronto.ca videotron.ca netidea.bc.ca ulaval.ca ualberta.ca dal.ca uottawa.ca uwo.ca connection.ca terago.ca accesscomm.ca ucc-net.ca sfu.ca yorku.ca ncf.ca rushcomm.ca eol.ca mcgill.ca oricom.ca vdn.ca amdsb.caumontreal.ca cyberus.ca knet.ca magma.camcmaster.ca usherbrooke.ca cgi.ca unb.ca sprintdsl.ca aol.com aracnet.com atlantabroadband.com attbi.com insightbb.com mchsi.com bbtel.com ccapcable.com cerfnet.com charter.com dancris.com execulink.com mindspring.com nexband.com rcn.com redshift.com ripnet.com rogers.com rr.com theplanet.com wideopenwest.comxmission.comcablenet-va.com charter-ala.com cox-internet.comquik.comgvtc.combah.com lan2wan.com westelcom.com power1.com mdsg-pacwest.com eschelon.comgvtel.com nettally.comoctapus.com firstlink.com hbci.comiinet.com naxs.com ntplx.com tfb.com srtnet.com theriver.com vcn.com visi.comwebhostplus.com winbeam.com gtlakes.com varian.com royaume.com primarydns.com netdoor.com registeredsite.com bearingpoint.comcore.com tvc-ip.com teksavvy.comopt2opt.com quiknet.com srt.com pcspeed.com cadvision.com mynethost.com 800hosting.com scrtc.com speede.com warpdriveonline.com wavecable.com lightyearcom.commidmaine.comprairieweb.com c2bandwidth.com innercite.com cintelecom.com hyperusa.com seanet.com cwia.commcttelecom.com osp-chicago.com primenet.comfire2wire.com calltech.comanobi.com telus.com hyatthsiagx.com spiritone.com aesirnetworks.com foxinternet.com willscot.comacetechusa.com aeanetwork.com alabanza.comarishost.comcalpop.com computechnv.com datapeer.comfatcow.com iwaynetworks.comlinuxwebnet.com mobilenetics.comskybitz.com tir.com unitedcolo.com zedcom.com zoolink.com crestviewcable.com mipops.com neteze.com wilnet1.com conninc.com asu.edu berkeley.edubrown.edu bucknell.educmich.edu cmu.edu colorado.educolumbia.educornell.edu csulb.edu csuohio.edu dartmouth.edu duke.edu ecu.edu fsu.edu furman.edu gac.edu gatech.edu harvard.edu hawaii.edu indiana.edu msu.edu ncsu.edunodak.edu pepperdine.edu psu.edu
Re: FW: The worst abuse e-mail ever, sverige.net
on Tue, Sep 21, 2004 at 02:04:18PM -0700, Sean Crandall wrote: We configure our DSL customers the same way you do. Static PVC, Static IP. Each user has a static IP and in 99% of the cases, we do not assign any dynamic IPs. However, I would say that it is safe to say that the majority of the ILECs here in the US provide DSL service where the IP is dynamic. Most of the time, it doesn't change, but it is very possible that the next time that the user logs in (most are also using PPPoE for the connection setup) that the DHCP server might give them another IP. As such, when we have seen our IP blocks get blocked strictly because of the rDNS entry having 'dsl' in it, a simple email to the admins explaining that we are not providing dynamic services has gotten our rDNS entries taken off of the blacklist. Why do you assume that an IP being static, but having generic rDNS showing it to be a DSL line, automatically makes it worthy of relaying or sending mail? I certainly don't make that assumption - rather the opposite, given my experience of the past three years. In my view of the universe, IPs with generically named rDNS should never emit mail except by way of a suitably configured MTA, which ought to have non-generic rDNS, preferably of the sort 'mail.$domain' where [EMAIL PROTECTED] is a live account manned by an abuse desk, rather than a generic '1-2-3-4.assignmenttype.technologytype.bigisp.example.net', where complaints to [EMAIL PROTECTED] may or may not make any difference. In the past 60 days, we've refused mail from ip-69-33-132-156.nyc.megapath.net (claimed to be 'hal.org', and sender was a yahoo.com account) and ip-66-80-96-99.aus.megapath.net (claimed to be 'asu.edu', and sender was an asu.edu account) and ip-66-80-90-195.iad.megapath.net (claimed to be 'ccs1.clinicofcosmeticsurgery.com', sent to an inactive account) and ip-66-80-206-37.lax.megapath.net (claimed to be 'mail.totexusa.com', sent to my account - I don't know anyone at 'totexusa.com'; both messages were backscatter from a joe job) Were we wrong to do so? I don't think so. Static or dynamic, makes little difference. Today's email services require more than the current status quo. And I haven't seen any reason to adjust my policy. I'm left with the overall impression from many on this thread that in the view of many ISPs, DNSBLs have removed the ISP's burden of policing their own networks. And that's a shame. Steve PS: this message certified ad hominem free :/ -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: Verizon IP's and ARIN Records
on Tue, Jun 08, 2004 at 01:00:55AM -0700, william(at)elan.net wrote: I'm not sure what will need to happen for ARIN to understand that validity and security of whois data is important and people rely on that all the time and they can't just ignore these issues. Unfortunetly most people who actually use their data also the ones who really dont have time or interest to participate in ARIN political process and as such are not heard at all. Well, one thing that has to happen is that ISPs and co-lo providers (such as Inflow, our former - note /former/ - provider) need to understand that validity and security of whois data is important and people rely on that all the time and they can't just ignore these issues. Which, unfortunately, is what Inflow refused to understand the entire time we were co-lo'd with them, and continue to ignore to this day. I'm not surprised to find that our old netblock is still tagged with my company's name, despite requests to have it updated: Request: 66.45.6.196 connected to whois.arin.net [192.149.252.43:43] ... Inflow NFLO-AR-2 (NET-66-45-0-0-1) 66.45.0.0 - 66.45.127.255 Hesketh INFLOW-55125-5697 (NET-66-45-6-192-1) 66.45.6.192 - 66.45.6.223 # ARIN WHOIS database, last updated 2004-06-07 19:15 # Enter ? for additional hints on searching ARIN's WHOIS database. ...because Inflow didn't give a damn when we were paying them, I can't imagine they'd give a damn now that we've decided to pay someone else. We tried for six months to get them to add an abuse contact field to our ARIN record and they wasted dozens of hours explaining that because it was optional they didn't have to do it, when the point was that it was /necessary/, or at least /being actively requested/, and that the way to keep customers isn't to explain how you don't have to do something, but rather to do what the customer asks. I'm glad that RFCi listing didn't have any real effect on our ability to send mail. :-/ But, as I've said, Inflow is our /former/ co-lo provider, so they can go to hell for all I care. But I really wish they, or someone, would clean up our old ARIN records so that the next spammer they host, or netblock that gets hijacked, doesn't suggest, via ARIN, that my company has anything to do with it. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy Cascading Style Sheets: Separating Content from Presentation, 2/e today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
Re: Barracuda Networks Spam Firewall
on Wed, May 19, 2004 at 03:12:29PM -0700, James Couzens wrote: On Tue, 2004-05-18 at 21:49, Eric A. Hall wrote: There's one rule that will wipe out ~90% of spam, but nobody seems to have written it yet. if URL IP addr is in China then score=100 ^^^ I beg to differ Eric A. Hall. snip According to Spamhaus, 200 known Spam Operations are responsible for 90% of your spam. Of the list currently available on their site, 142 of the known spammers are from a little country called THE UNITED STATES. That may be, and is probably quite true - but as Eric said, a majority of the /sites/ advertised in spam use China-based ISPs. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy Cascading Style Sheets: Separating Content from Presentation, 2/e today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
backscatter hosts (was: Re: Barracuda Networks Spam Firewall)
on Tue, May 18, 2004 at 04:01:40PM -0400, Todd Vierling wrote: On Mon, 17 May 2004, Jared B. Reimer wrote: : We had this problem when our inbound-smtp server ( the server the : barracuda is dumping mail to) was accepting all RCPT TOs : This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't : the only mailer that behaves this way. And, regardless of what the Barracuda box did, you should fix your qmail install. This behavior is no longer considered acceptable by the 'net at large, because accept-then-bounce is the biggest cause of virus spew bounceback spam. (As a result, people have begun widely blocking MXs that accept-then-bounce. You'd do yourself quite a favor to convert to reject-at-SMTP now, before you get blocked too.) At present, thanks to a recent massive joe job against one of the domains we host, I've got a list of ~16100 mailhosts that I no longer accept null sender mail* from. Most of them are running qmail, based on some unscientific analysis I did when compiling the list. All of them accepted, then bounced, mail from spammers HELO'ing with that domain back to the victim. Several hundred also sent us DSNs from virus forgeries. All of them were unnecessary. Sad, really, especially given that patches exist to fix this problem. Steve * or postmaster/Symantec_Antivirus/Webshield/VirusWall/JCT/etc. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy Cascading Style Sheets: Separating Content from Presentation, 2/e today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
Re: backscatter hosts
on Tue, May 18, 2004 at 11:37:49PM +0100, Chris Edwards wrote: Much as I hate to come to their defence, hotmail rejects unknown users during the dialog, and has done so for as long as I can remember. That may be so. But I've got 208 hotmail.com hosts backlisted for backscatter dreck such as this: --888-- From MAILER-DAEMON Wed Apr 14 16:17:33 2004 Received: from mc6-s2.hotmail.com (mc6-s2.bay6.hotmail.com [65.54.251.76]) by serrano.hesketh.net (8.12.9p1/8.12.8/NO-UCE-NO-UBE-NO-spam) with ESMTP id i3EKHVAh005383 for [EMAIL PROTECTED]; Wed, 14 Apr 2004 16:17:32 -0400 Received: from mc6-f11.hotmail.com ([65.54.252.147]) by mc6-s2.hotmail.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 13:17:36 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 14 Apr 2004 13:14:29 -0700 MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary=9B095B5ADSN=_01C42243E592A44406B1mc6?f11.hotmail. Message-ID: [EMAIL PROTECTED] Subject: Delivery Status Notification (Failure) X-OriginalArrivalTime: 14 Apr 2004 20:17:36.0210 (UTC) FILETIME=[86CCFB20:01C4225D] Content-Length: 7430 Lines: 142 This is a MIME-formatted message. Portions of this message may be unreadable without a MIME-capable mail program. --9B095B5ADSN=_01C42243E592A44406B1mc6?f11.hotmail. Content-Type: text/plain; charset=unicode-1-1-utf-7 This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. [EMAIL PROTECTED] --9B095B5ADSN=_01C42243E592A44406B1mc6?f11.hotmail. Content-Type: message/delivery-status Reporting-MTA: dns;mc6-f11.hotmail.com Received-From-MTA: dns;accsports.com Arrival-Date: Wed, 14 Apr 2004 13:14:19 -0700 Final-Recipient: rfc822;[EMAIL PROTECTED] Action: failed Status: 5.2.3 Diagnostic-Code: smtp;552 5.2.3 This message is larger than the current system limit or the recipient's mailbox is full. Create a shorter message body or remove attachments and try sending it again. --888-- Granted, it's a DSN for an over-quota user, not a nonexistent user, but the rejection happens after accept, and the DNS goes to the forged sender. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy Cascading Style Sheets: Separating Content from Presentation, 2/e today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
Re: backscatter hosts
on Tue, May 18, 2004 at 07:17:58PM -0400, Christopher X. Candreva wrote: On Tue, 18 May 2004, Steven Champeon wrote: Granted, it's a DSN for an over-quota user, not a nonexistent user, but the rejection happens after accept, and the DNS goes to the forged sender. OK Steve let me know when you have the sendmail ruleset to check quota on a remote host before accepting RCPT To: :-) Not the point. Point is that mail sent to a hotmail.com address from a forged sender was accepted, was not delivered, and the DSN sent to the forged sender. It's not really my business why a hotmail.com MX accepted mail it couldn't deliver. I could care less /why/. It's up to hotmail to fix their systems - I don't care how they perform that background check on quota. It's my business that over the past sixty days, we've had to reject over 23K of these, and had rejected some 130K in three weeks during March, at the peak of the joe job. At one point, backscatter accounted for 70% of my inbound email traffic on one host. Almost made the usual spam and virus look like background noise. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy Cascading Style Sheets: Separating Content from Presentation, 2/e today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
Re: Lazy network operators - NOT
on Sun, Apr 18, 2004 at 04:33:18PM +, Paul Vixie wrote: Maybe a stupid question... But if broadband providers aren't going to do this, and considering there are way less legitimate SMTP senders than broadband users, wouldn't it make more sense to whitelist known real SMTP sources rather than blacklist all addresses that potentially have a fake one? that's not a stupid question, and you're right that statistically it's better engineering to make a small list of good things than large lists of bad ones. IETF MARID, my own MAIL-FROM, somebody's SPF, yahoo's domainkeys, and lots of other people are working on what amounts to a whitelisting solution, and in a few more years you might actually see some results along those lines. We've had to do that here, simply to keep our own local antispam efforts from inadvertently blacklisting legit mail servers. So far, with relatively meager traffic over a year, I have a list of ~1300 legit mail servers I want to block but can't, due to their assumed legit-to-spam mail ratios, and another list of ~13,000 from whom I no longer accept null sender mail because they accept-then-bounce to forged senders. I haven't tried to assemble a list of all legit mail servers, though, as I've yet to see a definition of legit I can sit comfortably with. Some days, the line is drawn here, and others, it's drawn there. So, instead, I just keep track of those I'd like to block but can't, for whatever reason; those I block selectively; I whitelist a few more, and suffer. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy Cascading Style Sheets: Separating Content from Presentation, 2/e today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
Re: Lazy network operators
on Mon, Apr 12, 2004 at 12:31:59PM -0400, Robert Blayzor wrote: I can understand the reasoning behind what they are doing, but perhaps they are taking things in the wrong direction. Our abuse@ email address is just that, abused. Our abuse@ mailbox gets probably 500+ spams a day with maybe 2-3 legit emails that we need to look at. Sure we could run anti-spam measures on the abuse@ address but that probably isn't the way to go since most complaints to abuse@ are forward spam messages which could be marked and then missed. So don't do content-based filtering. [...] Having our techs/engineers go through the abuse@ box every day to play hide and seek is a bit of an agonizing task that nobody really wants, especially at the volume it is today. Isn't it their job? -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy Cascading Style Sheets: Separating Content from Presentation, 2/e today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
Re: Lazy network operators
on Mon, Apr 12, 2004 at 01:01:28PM -0400, Robert Blayzor wrote: Steven Champeon wrote: [...] Having our techs/engineers go through the abuse@ box every day to play hide and seek is a bit of an agonizing task that nobody really wants, especially at the volume it is today. Isn't it their job? Yes and no. They're responsible for addressing the real problems, and those issues are sometimes missed or lost to the shear volume of bogus messages that surround them. Sure, I understand, I'm in the same boat here, though on a smaller scale, but I don't see how disabling RFC-mandated role accounts will do anything but further erode confidence in ISPs' willingness to respond to complaints. To addess the same issue, I've tried various things over the past few months, such as rejecting all abuse/postmaster mail if the primary Content-Type is text/html, with a message saying that the sender should use plain text mail; rejecting postmaster to hosted domains asking the sender to use the postmaster address in the primary domain instead, etc. And I've only had *one* legitimate abuse report in seven years of hosting, and only a dozen or so legit postmaster complaints (it's the address I point people to in the event that their mail was improperly blocked). On the bright side, actually examining the bogus stuff hones skills in spam recognition, which should in theory at least make it easier on those who are doing the scanning. It's also managements job to try to streamline things so that engineers are not wasting valuable amounts of time on things like mailboxes full of spam. If I can optimize that task and save a few man hours a week, I will. Oh, and that's your right, certainly. But please don't switch to web based systems. I get spam via SMTP, I should be able to report it via SMTP. Asking me to switch to a Web browser is insane and will only serve to reduce the number of legitimate abuse reports, feeding the erroneous supposition that if spam goes unreported it isn't a problem. As of today, fully 60% of my incoming mail is spam; 30% are bounces from accept-then-bounce servers; and we're quickly approaching 99% spam for several of the domains we host mail for. The last thing we need is for ISPs to deal with their inbound problem by ignoring abuse reports or making it more difficult for victims to report spam or viruses originating from their networks. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy Cascading Style Sheets: Separating Content from Presentation, 2/e today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
Re: Need a cox.net mail server contact
on Wed, Mar 10, 2004 at 10:19:18PM -0800, Gregory Taylor wrote: The IP that 2mbit.com inhabits is on a Road Runner commercial block, which is allocated for small to mid-sized businesses. There is no reason for commercial cable networks to be blocked under the same pretenses that consumer cable networks are blocked. Well, except that they're often no more secure than anyone else, usually lack rDNS that might distinguish them from consumer grade networks, and you'd have to be insane to accept mail from any mail server with generic rDNS. Other than that, you're right. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Book publishing is second only to furniture delivery in slowness. -b. schneier
Re: SPAM Prevention/Blacklists
on Fri, Mar 05, 2004 at 07:36:36PM +, Paul Vixie wrote: reject_rbl_client blackholes.easynet.nl, reject_rbl_client dynablock.easynet.nl, reject_rbl_client proxies.easynet.nl FYI, easynet.nl stopped hosting their DNSBLs in December. http://groups.google.com/groups?selm=q60srv0prtpgqobe9icdlk4birg0t61v77%40thor.wirehub.nl -- hesketh.com/inc. v: (919) 834-2552 f: (919) 834-2554 w: http://hesketh.com Book publishing is second only to furniture delivery in slowness. -b. schneier
Re: Anti-spam System Idea
on Sat, Feb 14, 2004 at 03:55:40PM -0800, Tim Thorpe wrote: If these exist then why are we still having problems? See my reply to the thread SMTP relaying policies for Commercial ISP customers...? -- we have problems because the spammers are a lot smarter than any of us and can bounce from one infected host to another, in an attempt to evade network-specific traps, and few ISPs do anything at all to stop them. Why do we let customers who have been infected flood the networks with traffic as they do? Very good question. Should they not also be responsible for the security of their computers? Do we not do enough to educate? Yes, and no. -- hesketh.com/inc. v: (919) 834-2552 f: (919) 834-2554 w: http://hesketh.com Book publishing is second only to furniture delivery in slowness. -b. schneier
Re: SMTP relaying policies for Commercial ISP customers...?
on Fri, Feb 13, 2004 at 12:35:17PM -0500, Andy Dills wrote: For any responsible ISP, the problem is the spam coming into your mailservers, not leaving. As long as you quickly castrate the people who do relay spam through you, you're not going to have an egress spam problem. I beg to differ (though you did qualify your statement with responsible, so maybe this critique doesn't apply). Yes, anyone providing Internet services such as inbound mail has to deal with spam. But to assume that all spam goes through your outbound mail servers is simply not commensurate with the facts. Since 1/1/04, we've rejected many email messages on our servers as having originated from hosts with generic rDNS symptomatic of dynamic/broadband/dialup/etc. IP assignment. Of those that were rejected, here is a quick summary, showing the domain or ccTLD of the originating host for those representing 20 or more attempts. 585 comcast.net46 co.uk 402 rr.com 46 tiscali.nl 188 attbi.com 43 yahoo.com 175 pacbell.net41 rogers.com 165 ameritech.net 40 mchsi.com 130 shawcable.net 38 cgocable.net 128 adelphia.net 36 snet.net 125 optonline.net 35 mindspring.com 106 wanadoo.fr 34 interbusiness.it 105 verizon.net32 surfer.at 103 bellsouth.net 30 telus.net 89 charter.com30 go2lnk.com 88 dsl-verizon.net30 com.br 80 t-dialin.net 29 net.au 79 swbell.net 28 rima-tde.net 63 ne.jp 27 wideopenwest.com 61 videotron.ca 24 bbtt.de 58 net.il 22 nuvox.net 51 proxad.net 21 com.hk 48 com.tw 21 bbtec.net 48 a2000.nl 20 telia.com 20 charter-stl.com These are not messages originating through known ISP mail servers, which we have to a large extent offwhitelisted - meaning we don't reject, but rather add a header to, such messages so that the header can be used as part of a quarantine strategy. Any large ISP mailhost we've received spam through (such as the freemail providers who are the greatest source of Nigerian 419/lottery scams) is offwhitelisted and may be subject to further blocking on a case by case basis, or to further filtering. Some of the messages aggregated above may well have been virus or worm delivery attempts; I haven't analyzed the day-to-day breakdown, but I'd be surprised if MyDoom doesn't figure in to a large extent in the cases documented above. But that is of no consequence; spam or virus messages both constitute abuse by out-of-band, often compromised, hosts. The problem of abusive mail originating from dynamic and otherwise non-sanctioned sources is real; viruses such as SoBig are suspected of being used in a vast net of compromised hosts, to evade other filtering strategies. Sobig.a and the Spam You Receive Today - LURHQ http://www.lurhq.com/sobig.html Sobig.e - Evolution of the Worm - LURHQ http://www.lurhq.com/sobig-e.html Sobig.f Examined - LURHQ http://www.lurhq.com/sobig-f.html In an eight-minute window on one of my servers yesterday, I saw the following: -- WKS Q 12:12:54 (9351) to: [EMAIL PROTECTED] from: [EMAIL PROTECTED] at 68.59.188.188 (pcp02265132pcs.batlfl01.tn.comcast.net) -- WKS Q 12:13:23 (9356) to: [EMAIL PROTECTED] from: [EMAIL PROTECTED] at 81.9.232.163 (cmr-81-9-232-163.telecable.es) -- WKS Q 12:15:21 (9513) to: [EMAIL PROTECTED] from: [EMAIL PROTECTED] at 200.55.72.231 (200-55-72-231.dsl.prima.net.ar) -- WKS Q 12:15:49 (9519) to: [EMAIL PROTECTED] from: [EMAIL PROTECTED] at 142.169.46.107 (c142.169.46-107.clta.globetrotter.net) -- WKS Q 12:15:51 (9520) to: [EMAIL PROTECTED] from: [EMAIL PROTECTED] at 142.165.147.216 (hsdbsk142-165-147-216.sasknet.sk.ca) -- WKS Q 12:15:56 (9521) to: [EMAIL PROTECTED] from: [EMAIL PROTECTED] at 141.158.119.119 (pool-141-158-119-119.pitt.east.verizon.net) -- WKS Q 12:17:03 (9556) to: [EMAIL PROTECTED] from: [EMAIL PROTECTED] at 81.59.87.42 (dslam42-87-59-81.dyndsl.zonnet.nl)
Re: New mail blocks result of Ralsky's latest attacks?
on Fri, Oct 10, 2003 at 08:47:51PM +0530, Suresh Ramasubramanian wrote:
Set up header checks in sendmail / postfix to block all mail with
Received: headers showing Ralsky IPs. PCRE header checks in postfix
would be like -
snip
Sendmail rulesets to block Ralsky:
KRalsky1 regex [EMAIL PROTECTED] ^.*(\[|\(|\s)211\.158\.[3456789]
KRalsky2 regex [EMAIL PROTECTED] ^.*(\[|\(|\s)218\.70\.1[345]
KRalsky3 regex [EMAIL PROTECTED] ^.*(\[|\(|\s)219\.153\.1[45]
KRalsky4 regex [EMAIL PROTECTED] ^.*(\[|\(|\s)218\.10\.57
KRalsky5 regex [EMAIL PROTECTED] ^.*(\[|\(|\s)218\.70\.1[01]
KRalsky6 regex [EMAIL PROTECTED] ^.*(\[|\(|\s)218\.70\.[89]
KReceivedChecks sequence Ralsky1 Ralsky2 Ralsky3 Ralsky4 Ralsky5 Ralsky6
HReceived: $check_header_Received
Scheck_header_Received
R$* $: $1 $| $(ReceivedChecks ${currHeader} $)
R$* $| @SPAM$#error $@ 5.7.1 $: 550 Message rejected; suspected spam
signature.
R$* $| $* $: $1
This will not help to block direct SMTP AUTH attacks; but they should block
mail from other compromised servers, provided they don't munge the headers.
I've been running these rules for several weeks without incident.
HTH,
Steve
--
hesketh.com/inc. v: (919) 834-2552 f: (919) 834-2554 w: http://hesketh.com
Book publishing is second only to furniture delivery in slowness. -b. schneier
