Troubleshooting versus support
When we talk about 'support', especially things like 'vendor support', I think that there are actually two general things that are getting lumped under the same label: issues that you could have dealt with on your own if you knew enough, and things that are broken.
Although I don't have really good names for them, let's call the first sort of issue 'troubleshooting' and the second sort 'support'.
Unless the vendor dropped the ball on their documentation (which is certainly known to happen), calling the vendor up for troubleshooting is your fault, because you've failed to read or to understand (or you have decided that calling the vendor is faster than reading). In a sense you are wasting the vendor's time and asking them to do your work for you.
Support issues, genuinely broken things, are the vendor's fault, not yours. No amount of understanding the documentation or reading the FAQ can help (except perhaps to say 'this is a known bug'). Fixing the problem is not your work, it's the vendor's.
The difference matters in part because reasonable pricing is different between troubleshooting and support. It's hard to object to being charged each time you want a vendor to hold your hand, or to a vendor with flat rate troubleshooting saying 'you're asking for too much hand holding'. But being charged for each broken thing you discover, or hearing 'this is costing us too much to fix, go away' is infuriating for reasons I covered in more depth in SupportMythPartII.
Working in a heavily technical environment as I do, I don't care very much about a vendor's ability to do troubleshooting; we'll handle that ourselves. I do care quite a bit about the vendor being sane about support.
Weekly spam summary on October 8th, 2005
This week we received 12,111 email messages from 242 different IP addresses. Our SMTP server handled 61,080 sessions from 6,951 different IP addresses. Both email volume and session volume is up from last week, despite us being cut off from Level 3 customers for part of the week. (The University of Toronto gets core connectivity from Cogent, and you may have heard about the spat Cogent and Level 3 had between Wednesday and Friday.)
Overall connections are up again from last week: 299,200 connections from at least 41,000 different IP addresses. Our SMTP frontend once again hit a highwater of 50 maximum connections in flight. (I really need to be able to do a day by day breakdown of these numbers, to see when the connection rates jump.)
Looking back to the first of these reports in SpamStats-2005-06-25 it's tempting to draw some overall conclusions. Unfortunately it would be misleading, since our connection-time checking process is different now than it was back then. The growth in connection rates and the changes in other statistics may be in large part because we are now more aggressive about telling people to come back later.
(At the same time I think it's clear on a week to week basis that we have seen significant jumps in the volume of bad stuff.)
Kernel level SMTP blocks:
Host/Mask Packets Bytes 220.127.116.11/10 17702 858K 18.104.22.168 13785 662K 22.214.171.124/12 10500 517K 126.96.36.199/24 9717 506K 188.8.131.52/24 8949 413K 184.108.40.206 8804 403K 220.127.116.11 7366 354K 18.104.22.168 7340 352K 22.214.171.124/11 6826 331K 126.96.36.199 6257 300K
China comes in like gangbusters for once, specifically chinanet.cn.net (all three of the large netblocks in the top ten are theirs). I believe this may be a record placement of large netblocks in the top ten listing. tin.it and Netvigator continue their strong showings.
- 188.8.131.52, a terra.es machine listed for bad reverse DNS data, has made the top 10 before (in SpamSummary-2005-09-17).
- 184.108.40.206, smtp.capinc.com, is SPEWS-listed as part of Comcast/ATTBI.
- 220.127.116.11, in QWEST space, was rejected because of bad reverse DNS; QWEST has hosted enough spammers that we now require anyone from their network space to have valid reverse DNS before we'll talk to them.
- and finally, 18.104.22.168 and 22.214.171.124 did the usual thing of
pumping out unresolvable
This is clearly an atypical week; most weeks, the leading cause of
getting into our kernel-level filters is unresolvable
Connection-time rejection stats:
25755 total 12244 dynamic IP 6513 bad or no reverse DNS 1852 class bl-cbl 1434 class bl-spews 1044 class bl-dsbl 556 class bl-sbl 549 bad Chinese networks 494 class bl-ordb 285 class bl-sdul 133 class bl-njabl 8 class bl-opm
The stats are broadly the same as last week. Apart from 126.96.36.199, almost singlehandedly responsible for the sudden appearance of 'bad Chinese networks' in the list of noteworthy things, no single source stands out.
|what||# this week||(distinct IPs)||# last week||(distinct IPs)|
Since both of these numbers are up from last week, it's probably
spammers forging us (yet again) as the
MAIL FROM in their spam runs.
(Technical issues make the 'last week' numbers from this table not quite match up with the 'this week' numbers in the same report last week. I'm switching some manual procedures around so that the numbers should match up better in the future; the divergence has to do with when logfiles are rolled over and how that interacts with the weekly reboot.)