ingress SMTP

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*

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.