[Resolved] What Triggers look at my domain during parsing?

[patrickg]

Hi:

Long time spamcop reporting user, but first time post in forums.

I have been trying to figure out exactly what triggers a "look" at my domain's mx record as the header is parsed. I assumed it was always because our domain was spoofed somewhere in the header.

But that's not true I've come to learn. I submitted a spam that had no evidence of spoofing in the header, and when I reviewed the report, I saw the parser looked at my mx twice according to the report.

Not a big deal as it does disregard me. I'm curious as to what else could trigger that lookup besides a spoof in the header.

Thanks in advance for any thoughts or answers.

patrickg

[StevenUnderwood]

I have been trying to figure out exactly what triggers a "look" at my domain's mx record as the header is parsed. I assumed it was always because our domain was spoofed somewhere in the header.

But that's not true I've come to learn. I submitted a spam that had no evidence of spoofing in the header, and when I reviewed the report, I saw the parser looked at my mx twice according to the report.

It would be easier to work with real headers. If you could post a Tracking URL for one you had questions on we could get specific.

In general, any parse should start at your server because that should be the last header in the thread. It will then work back to where your server go the message, etc.

[patrickg]

It would be easier to work with real headers. If you could post a Tracking URL for one you had questions on we could get specific.

In general, any parse should start at your server because that should be the last header in the thread. It will then work back to where your server go the message, etc.

Thanks Steve. I assume ths is the link you need:

http://www.spamcop.net/sc?id=z1216175083zf...fa7248a93e381bz

You'll see during parsing my domain was checked twice - normally it's not listed at all, unless, as I had always assumed, my domain was spoofed.

patrickg

[StevenUnderwood]

Thanks Steve. I assume ths is the link you need:

http://www.spamcop.net/sc?id=z1216175083zf...fa7248a93e381bz

You'll see during parsing my domain was checked twice - normally it's not listed at all, unless, as I had always assumed, my domain was spoofed.

OK. If terraempresas.com.br is your personal domain, then it looks like this message was originally sent from host 200.176.131.33 = wh51.terraempresas.com.br to host 200.154.117.75 = smtp-wh.terraempresas.com.br to mail.galadv.com then some internal routing to your mailbox.

It is possible that the 200.176.131.33 machine received the message from something called webpoint on that machine, but the headers are not indicating beyond that, so spamcop can trace no further back. If so, it is possible there is a form or webserver that has been comprimised.

If terraempresas.com.br is your domain, it is not wise to be reporting this message as you are reporting yourself or another customer of your ISP. It is usually better to complain through your normal support channels in that case.

[patrickg]

OK. If terraempresas.com.br is your personal domain, then it looks like this message was originally sent from host 200.176.131.33 = wh51.terraempresas.com.br to host 200.154.117.75 = smtp-wh.terraempresas.com.br to mail.galadv.com then some internal routing to your mailbox.

It is possible that the 200.176.131.33 machine received the message from something called webpoint on that machine, but the headers are not indicating beyond that, so spamcop can trace no further back. If so, it is possible there is a form or webserver that has been comprimised.

If terraempresas.com.br is your domain, it is not wise to be reporting this message as you are reporting yourself or another customer of your ISP. It is usually better to complain through your normal support channels in that case.

Steve:

I should have said which was my domain, my apologies.

Actually my mailserver is mail.galadv.com, and as you can see from the header, there appears to be no spoofing. terraempresas.com.br is (presumably) the spam source.

But as I mentioned before, the parsing process looked and compared our mx with various ip's from the header (maybe the body too?) twice before disregarding my domain as the source of spam.

I am wondering what causes this besides spoofing - given the fact that most of the time during the parsing, spamcop never looks at galadv.com (since I am the recipient?)

Thanks,

Pat

[Farelf]

Pat,

It looks to me that the parser is simply working through the headers. There does seem to be an unusual amount of internal passing around - but that would be to do with your internal configurations, not any artifact of the parser. Maybe that (your set up) has changed recently. Are the parses now all looking like the one you have shown? I suppose we would get a better idea if we saw another example, this one of a parse you consider normal.

[patrickg]

It looks to me that the parser is simply working through the headers. There does seem to be an unusual amount of internal passing around - but that would be to do with your internal configurations, not any artifact of the parser. Maybe that (your set up) has changed recently. Are the parses now all looking like the one you have shown? I suppose we would get a better idea if we saw another example, this one of a parse you consider normal.

Hi Farelf:

We use postfix here which recieves then passes emails on to amavis for virus and spam filtering and then back for final delivery, hence the internal passing around - took me a while to get used to that.

Here's a very typical parse:

http://www.spamcop.net/sc?id=z1216600859zb...260b741183649dz

as you can see, no reference or checking done on galadv.com

It had always been unusual to see it include my domain in the parsing, and those times that it did - I noticed it was due to the fact that the spammer had spoofed my domain in the header somewhere. It didn't give me any concern as Spamcop was obviously parsing well enough not to "buy" into the spoof and name me the spammer.

This question as to what triggers the "look" at my domain came up as we have enabled a couple defenses specifically against spoofed email. Suffice it to say at the expense of a tedious explanation, mail with our domain spoofed in the header should be rejected.

When I saw we were listed in the parsing report twice, I assumed something spoofed had gotten through in spite of defenses. But when I examined that header, saw no evidence of a spoof and began wondering exactly when and why does our mx record for galadv.com get compared with the available IPs in the header.

Thanks for your time and thoughts,

patrickg

[Miss Betsy]

I haven't looked at the parsing results, but as long as the parse is doing its thing correctly, I would not worry. The parser is software and if you have ever written code, or maybe some other method of sorting things, you know how complicated it can get. The software has to do what it is programmed to do in order to account for various scenarios. Perhaps because of the number of internal handoffs, the parser has to look up the MXs several times. I don't know. But I do know that the code to create the parser has not been duplicated so that many people can use it successfully. That may mean very complicated code (in fact, IIRC, when it was open source, people gave up deciphering how it worked).

Miss Betsy

[Farelf]

Pat,

looking at the newer link, I see no significant difference in the way the parser is working. In both cases it it just ratcheting down the headers until it runs out of chain. In other words, the "trigger" is simply the servers adding "Received:" lines during transit. The parser does what it is supposed to. I would go along with Miss Betsy's advice - don't worry.

[StevenUnderwood]

Here's a very typical parse:

http://www.spamcop.net/sc?id=z1216600859zb...260b741183649dz

as you can see, no reference or checking done on galadv.com

I am very confused. The 2 parses look identical to me once they reach your server. I don't see anywhere in either of them they are checking your MX record.

The only line even close is:

200.154.117.75 is not an MX for mail.galadv.com

200.154.117.75 is not an MX for mail.galadv.com

That line is checking to see if the IP (not yours) that did some forwarding is an MX for any of the domains seen to that point. It is trying to determine whether to trust the forward and look to the next IP address as a source or to ignore the next IP address. It is looking to see if that server is likely supposed to accept email for your domain or not. The answer comes later in the lines:

ips are close enough

200.176.131.33 is close to an MX (200.176.131.2) for terraempresas.com.br

200.176.131.33 is mx

You will get these messages anytime a server forwards a message from another source i.e. the server connecting to your server is clearly identifying where it got the message.

This is nothing to worry about, just the normal working of the parser trying to determine the real source of the message.

[patrickg]

Thank you Farelf, Miss Betsy and Steve. Appreciate you all taking time to look!

Actually Steve, you're getting close to the crux of my question.

The only line even close is:

200.154.117.75 is not an MX for mail.galadv.com

200.154.117.75 is not an MX for mail.galadv.com

Why are these 2 lines in the first parsing, yet not in the second - I'm not seeing any substantial difference in the headers - well, other than source of spam is different. But in each, it is received by my mail server by some sender, yet in the first parsing, spamcop checks my MX against an IP, and in the second, it did not. Piqued my curiosity enough to post.

I don't mean to suggest anything is "wrong" or "broken". You are all correct - spamcop is correctly parsing and disregarding my domain as not the spammer. Thankful for that!

Really, I'm not worried - just a very curious cat ;-)

Thanks again.

[StevenUnderwood]

Actually Steve, you're getting close to the crux of my question.

Why are these 2 lines in the first parsing, yet not in the second - I'm not seeing any substantial difference in the headers - well, other than source of spam is different. But in each, it is received by my mail server by some sender, yet in the first parsing, spamcop checks my MX against an IP, and in the second, it did not. Piqued my curiosity enough to post.

The issue is, if the machine [A] connecting to your server is the only header that exists, that is known as the source. No further processing is needed. No MX tests are needed.

If that server [A] that connects to your server includes a header where it claims to have received the message, spamcop needs to test to see if it can trust this servers [A] information to locate the true source of the message. One of those tests is to see if the IP address of the connecting server [A] is an MX record for one of the domains seen in the headers, therefore is supposed to be handling this message. If that relationship can not be established, then the parser stops at that IP address [A]. In this case, that relationship is established and the server [A] is accepted as a valid handler of mail for the terraempresas.com.br domain and uses the machine as the true source.

It is checking if server [A] is an MX )or near an MX) for your domain to guess whether it should be handling your messages. It is also checking the domain that sent the message and finds the IP is close to the IP for the MX for that domain and assumes it is a valid handler for messages from that domain (outgoing server).

I hope this helps.

[patrickg]

The issue is, if the machine [A] connecting to your server is the only header that exists, that is known as the source. No further processing is needed. No MX tests are needed.

I hope this helps.

Steve:

Ahh, I believe a glimmer of light is beginning to penetrate my denseness.

So if the mx matches the sender, parser is "happy" and looks no further, but if it doesn't, it continues on looking until it finds one, and has no choice (I suppose) but to look at my domain as a possibility. That makes sense to me and I hope I've stated it correctly.

My curiosity is satisfied and my question is resolved.

Again, thanks very much Steve for your help, and to all who responded.

patrickg

[StevenUnderwood]

I think you've got it. Marking this resolved.