I am an admin for a company with 400+ exchange servers. I also have several routing connectors with several servers. This means that an email coming into my account can take several routes.

To boot, reporting spam is generally left up to a handful of people. This means that when I cut and paste headers, it always kills out after the first hop of an unrecognized host. All of my hosts are <hostname>.firmwide.corp.<domain>.com. Is there a way to wildcard this in the mailhosts configuration? The domain/hosts firmwide.corp.<domain>.com is listed, but my parsing still stops when it reaches one of my non-specified (in mailhost config) hosts.

Welcome - someone may chip in with an answer but maybe your best bet is to get the help of the SC Administrator, Don D'Mininion at service[at]admin.spamcop.net - he comes by here when he can but e-mail contact will get him more quickly.

I can probably fix that for you.

Send me your login email address and I'll look into it. A "Tracking URL" from the top of the SpamCop page when you parse one of the spams would help.

Email me directly. Do not post that information here.

service[at]admin.spamcop.net

- Don D'Minion - SpamCop Admin -

Don wants your Reporting System login details. It may or may not be the same as 'here' but I believe that this needs to be pointed out.

As Don suggests, this really shouldn't be much of a hurdle, as compared to Yahoo with thousands of servers involved.

I'm not sure exactly (especially with no data to work with) as to how Don can actually fix this. What you're stating is that 'you' are trying to report someone else's e-mail. If this e-mail is somehow entering 'your' system from numerous outside sources that your users add in to the mix, this will be a continuing problem. But again, this is just the thought brought on by a lack of sufficient detail. Specifically, if all e-mail was actually directly incoming to 'your' servers, not sure why there'd be an issue. However, if the e-mail s forwarded, POP'd, whatever by users from other sources, then those 'other/external' sources would continue to fail until 'you' added all of them to 'your' MailHost Configuration set. Technically, it would really seem that MailHost Configuration of "your" Reporting Account wouldn't be the correct way to go in this scenario. Though also noting that Reporting someone else's spam has never been recommended, and most others that tried ran into issues, just as you seem to be pointing out.

I administer a small network and I report spam from any box on the network without any problems, so take that last bit of advice with a grain of salt. There's no policy against doing so, is there?

DT

No policy that I know of. Again, some others that have tried ths in the past ran into issue, be it the MailHost Configuration, running into the limits on quantities of spam submitted, etc. But as stated above, I'm shooting a bit in the dark .... the starting post kind of implies a singular Domain involved, but that doesn't seem to lead to the issues and problems suggested ... though perhaps there is an assumption that all involved servers are correctly configured with a FQDN ...?????

As suggested un so many places, a Tracking URL would sure help define some of the variables involved.

...IMHO, this seems to be [emphasis via italics is mine] (although I can see where the last sentence might be interpreted as meaning that it is okay in this case):

No, Steve...if you're saying that "someone else's spam" phrase from the prohibition against reporting the internal bounced spam found within a bounce message applies here, I'd say you're incorrect. IIUC, network admins can and do submit reports on spam arriving at (or intended for) mailboxes under their control. That's not the same as reporting something from some stranger's mailbox on an unrelated system.

Perhaps Don will drop by and clarify.

DT

Hi, DT,
...Yes, I see where you're coming from -- and that's to what I was referring when I wrote "(although I can see where the last sentence might be interpreted as meaning that it is okay in this case)...." <g>

FWIW I think David has it right (though Don might mutter "Assumptions!") -Seems to me to precisely match the requirement of familiarity with the network -- therefore being within the scope of allowed/expected/supported/recommended/desired practice. The coverage of whole domain(s) in reporting coverage is probably a good thing, when it happens - not unlike SenderBase monitoring in the sense of being a complete expression of the experience of that particular part of the internet and a proper measure of volumes for the same, as well as a "Don't tread on me!" flag for what were once called 'mainsleaze' spammers (there seem to be a few of them left ).

There is no policy against an admin reporting spam that comes into his network no matter what mailbox it ends up in.

There *is* a policy against filing false reports against innocent bystanders, such as the relay server that is forwarding mail for one of the admin's users who also gets email services from another network.

That does not normally present a parse problem. As long as all the servers properly identify themselves, the parse will chain back to the origin point.

If the admin wants to register Mailhosts, he needs to account for all the other networks his users get service from or SpamCop will tag the relay server as the source every time.

By "relay server" I mean the outgoing mailserver that is legitimately forwarding mail as instructed by the user. I specifically do NOT mean open relays.

- Don D'Minion - SpamCop Admin -

I am feeling very comfortable in that this is just what I stated in my Linear Post #4 ..... while still shooting in the dark due to the lack of follow-up data from the Topic-starter.

Thanks Don, that's information worth knowing (undoubtedly apparent beforehand to some, but not to me), a definite "Aha" moment.

JIC there are others like me (I keep looking but it's mostly a matter of 'faith' ) ... "SpamCop will tag the relay server as the source every time" - which would be (sort of) like the parsing difference between
http://www.spamcop.net/sc?id=z2504224540ze...a4f637922a0576z (mailhosts set) and
http://www.spamcop.net/sc?id=z2504298945z0...3939b4206aa289z (no hosts)
- just to see that relay factor in action/in context.

The critical bit - parsing after
"Received: from 206.46.232.11 ([116.74.118.3]) by vms169133.mailsrvcs.net ..." branching to either
"Verizon received mail from sending system 116.74.118.3" (hosting) or
"vms169133.mailsrvcs.net looks like a dynamic host, untrusted as relay" (no hosting).

So, anyway, that's why/how people inadvertently report their own provider when there are certain kinds of routing changes etc. Much clearer now. Bear with me, I'm slow/need to be shown but ... I'm getting there.