Wow, lots of responses already. Thanks, good discussion. I should clarify a little, that it's not necessarily about "blanket" port blocking or denying "random" ports as threats are perceived, but where needed in a well thought-out manner and trying to take customer needs [stated or observed] into account first. And back it up with AUP verbiage. There must be plenty of places where it just makes sense, and others where it's borderline, iffy, or unmanageable. One has to start *someplace*. Oh, and don't get me started about abuse-desk competency, or even existence, especially in the big providers. I'll bet most of them can't even find the *rack* where the autoresponder machine is, let alone actually figure out why its disk has been full for six months. Related question, now that some discussion has started: why the F does Gmail refuse to put real, identifiable injection-path headers in mail they relay out? The current "policy" only protects spammer identities behind a meaningless 10.x and is completely at odds with what almost every other freemail provider does, which of course breaks any receiving-end model. Who's here from Google that I can chat with about this? _H*
on Wed, Sep 03, 2008 at 05:15:41PM +0000, *Hobbit* wrote:
Related question, now that some discussion has started: why the F does Gmail refuse to put real, identifiable injection-path headers in mail they relay out? The current "policy" only protects spammer identities behind a meaningless 10.x and is completely at odds with what almost every other freemail provider does, which of course breaks any receiving-end model. Who's here from Google that I can chat with about this?
Dunno who's here from Google, but every time I've asked about this (as the basis for a discussion of why they do such a sucky job of blocking 419 scams, which we otherwise block by injection point analysis) I've been told that it's a "privacy" issue. I long suspected it was just a side effect of an inflexible network architecture, but have been assured that, no, it's the privacy issue. And yes, this is completely at odds with the fact that they *do* put injection point IP audit trail into mail they relay via SMTP. In the end, it's an idiotic policy, and I hope they wake up and fix it. In the meantime, I'm reporting every 419 scam I get from them. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)747-9073 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
participants (2)
-
hobbit＠avian.org -
Steven Champeon