Wandering Thoughts archives

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
61.128.0.0/10         17702    858K
66.92.140.53          13785    662K
202.96.0.0/12         10500    517K
212.216.176.0/24       9717    506K
218.102.53.0/24        8949    413K
213.4.149.69           8804    403K
24.173.71.171          7366    354K
24.147.105.129         7340    352K
220.160.0.0/11         6826    331K
65.124.82.6            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.

• 213.4.149.69, a terra.es machine listed for bad reverse DNS data, has made the top 10 before (in SpamSummary-2005-09-17).
• 24.147.105.129, smtp.capinc.com, is SPEWS-listed as part of Comcast/ATTBI.
• 65.124.82.6, 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, 66.92.140.53 and 24.173.71.171 did the usual thing of pumping out unresolvable HELO greetings.

This is clearly an atypical week; most weeks, the leading cause of getting into our kernel-level filters is unresolvable HELO greetings.

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 210.51.25.177, almost singlehandedly responsible for the sudden appearance of 'bad Chinese networks' in the list of noteworthy things, no single source stands out.

Other stats:

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.)