Jump to content

Address harvesting from reports?


btech

Recommended Posts

btech,

If your address were sold to others, it would be quite a joke on them. In a separate post, I mentioned how my un-munged reports caused me to apparently be removed from an East European phishing list. The more I report to SpamCop, the less spam I get.

However, 500 letters a day would be considered a denial-of-service attack. You must be dealing with different people than I, people you've really ticked off. Though I have a dynamic ip address, I've no doubt there are organizations that can pick me out from my ISP and my punctuation. :-)

Only once did my account receive that many letters. Eight years ago I reported some voting irregularities in Florida, here in the US, to the appropriate politicians and officials of two political parties. A week later, and every election year since, that address is flooded daily with invitations to pornographic web sites in the Far East. When you receive that many letters, it's personal. (Makes you wonder who would knock on my door, if I clicked one.)

That was actually my previous point... I see many 'report to' addresses of throwaway email addresses (which seems suspect to me) and some ISP/hosts that keep receiving email and never bounce (which are non-'abuse' addresses).

It seems to me that a spammer could pay that person an amount to have all of the SC reports forwarded to them. How else can anyone explain how my CESMAIL address is now the #1 target of the 500+ spam messages I get a day? I have NEVER emailed from that address (except to SC admins) and never reference it anywhere.

<SNIP>

.. and I'm sure others are 'in bed' with spammers and being paid off to forward reports. Their email addresses don't bounce like many, so they obviously read or do something with the abuse reports.

Link to comment
Share on other sites

...OK, I just reported a message that claimed to be from me, to me (horray!), but I found an error in the munging. I have munging set 'on' for all reports, yet I found the 'Delivered-To' address was intact. ...
Non-munging when your address is in the forged 'From:'/'Return-Path:' addresses is/was a known issue. I thought I saw an example where this might have changed recently, but I guess not. Trouble is those lines are important evidence of forgery and may be required to demonstrate such. I think. Not sure why that would affect other lines but at a guess, when that agent of the parser hits an unmungeable line (process order unknown) it stops trying.
Link to comment
Share on other sites

  • 2 weeks later...

Here's an interesting change in reporting.... it seems the system is not only munging my address, but it's also picking out my address in the subject line and munging it. For example "We caught you in the act x!"

Odd thing is, it seems to be sporadic and not all reports are munged in this fashion.

Example: http://www.spamcop.net/sc?id=z1932681373z0...1f60890cc19357z

Notice:

Subject: video Kick-up for x 

Link to comment
Share on other sites

Here's an interesting change in reporting.... it seems the system is not only munging my address, but it's also picking out my address in the subject line and munging it.
The parse is supposed to look for the "To" address and munge it wherever it finds it. The parse also automatically munges other addresses in the headers. such as the "For" address and the "Delivered-To" address regardless of what they are.

Sometimes munging the username when it appears alone in the subject line is a plus. To my knowledge, the parse has not been trained to do that. I couldn't duplicate it.

Example:

To: address: tail[at]furpants.com

Subject: video Kick-up for tail

Munged subject: video Kick-up for x

- Don D'Minion - SpamCop Admin -

.

Link to comment
Share on other sites

The parse is supposed to look for the "To" address and munge it wherever it finds it. The parse also automatically munges other addresses in the headers. such as the "For" address and the "Delivered-To" address regardless of what they are.

This does not match the data discussed/seen in Linear Posts #24 and 25 .... the Tracking URL provided in Linear Post #24. Again noting the 'duplicate' lines involved in that set of headers. One could assume that the parser handled the 'first set' and somehow ignored the 'second set' ..????

Link to comment
Share on other sites

This does not match the data discussed/seen in Linear Posts #24 and 25 .... the Tracking URL provided in Linear Post #24. Again noting the 'duplicate' lines involved in that set of headers. One could assume that the parser handled the 'first set' and somehow ignored the 'second set' ..????
It might not match the discussion, but I think it matches the facts.

- Don -

Link to comment
Share on other sites

It might not match the discussion, but I think it matches the facts.

???? I just checked the example Tracking URL once again .... the discrepancy again is seen in the 'duplicate' (?) Delivered-To: and X-RCPT-TO; lines seen in that header .... noting that this was the actual question asked in Linear Post #24. Why only one 'set' of these is munged, the other left intact?

Actually, I'll note that there are three Delivered-To: liones in that header, so should be stating that two are munged, one is not. The first is probably from JT's server, the second might also be JT's server .... so perhaps, it is as I conjectured in my Linear Post #25, perhaps what you are implying here, .. the Delivered-To: addresses and the To: address do not match the un-munged address in question.

Guess it's up to btech to reply with whether his question has yet been answered or not.

Link to comment
Share on other sites

???? I just checked the example Tracking URL once again .... the discrepancy again is seen in the 'duplicate' (?) Delivered-To: and X-RCPT-TO; lines seen in that header
I didn't say anything about the X-RCPT-TO lines.

noting that this was the actual question asked in Linear Post #24. Why only one 'set' of these is munged, the other left intact?
I don't know. Maybe because one of them contained the user's email address and the other didn't.

Actually, I'll note that there are three Delivered-To: liones in that header
The third Delivered-To: lion has a very oddly constructed email address. It could be that the system didn't recognize it as an email address.

perhaps what you are implying here, .. the Delivered-To: addresses and the To: address do not match the un-munged address in question.
I'm implying that the Delivered-To: addresses are supposed to be always munged regardless of what address is in the line. I don't know what the actual code says. I thought it was looking for email addresses in the Delivered-To: lions, as opposed to always munging the contents of the Delivered-To: lion.

- Don -

.

Link to comment
Share on other sites

I didn't say anything about the X-RCPT-TO lines.

I only mentioned it because it was one of the lines 'duplicated' within the headers ... and it was munged in one instance, not in the other. I agree, that as an X-line item, it would normally tend to be ignored. But again, guessing that the contents of those two lines differed.

I don't know. Maybe because one of them contained the user's email address and the other didn't.

That's what I've been conjecturing, but only btech would know for sure (assuming that even your access to the actual submittal would also have the minged data at this point)

The third Delivered-To: lion has a very oddly constructed email address. It could be that the system didn't recognize it as an email address.

I won't comjecture about the parsing code, but .... the construct isn't any different than what JT's e-mail servers do for e-mail delived via his system .... basically pre-pending a version of the Domain name to the user account data.

I'm implying that the Delivered-To: addresses are supposed to be always munged regardless of what address is in the line. I don't know what the actual code says. I thought it was looking for email addresses in the Delivered-To: lions, as opposed to always munging the contents of the Delivered-To: lion.

Again, I believe we are in agreement here, missing is the actual content of those involved fields in the header lines. If all you see is the same thing 'we' see, then the answer has to come from btech.

PM sent to ask again about those little details.

Link to comment
Share on other sites

That's what I've been conjecturing, but only btech would know for sure (assuming that even your access to the actual submittal would also have the minged data at this point)
I can use the code in a Tracking URL to see the unmunged raw headers of a spam.

- Don -

.

Link to comment
Share on other sites

I can use the code in a Tracking URL to see the unmunged raw headers of a spam.

Not to continue to harp about it, but wouldn't that seem to state that you could see whether the content of the un-munged lines do in fact differ from the To: line data? Your answer could bring that part of the query to a close.

Link to comment
Share on other sites

I have to be honest, I don't know much of this stuff, but the 'delivered to' is the same as the name that was made into 'x' in the subject line and is the same address as the rest that were munged in the report.

But, here's one that did NOT munge the subject line. http://www.spamcop.net/sc?id=z1941861991zc...e04e894aa6ce7dz

I'll leave it to you experts to see the differences in the two reports that could cause this discrepancy.

Link to comment
Share on other sites

OK, see in the second report how it says my name in the subject? That was munged with an 'x' in the first report I posted and is the address before the '[at]' symbol in my email address. That's the discrepancy I noted... it munges that subject line somtimes, but not others.

Link to comment
Share on other sites

state that you could see whether the content of the un-munged lines do in fact differ from the To: line data?
That's correct. The addresses are different. Hence the wording of my earlier statement.

However, it was that previous statement that had me asking all the follow-on questions.

The parse also automatically munges other addresses in the headers. such as the "For" address and the "Delivered-To" address regardless of what they are.

Again, three Delivered-To: lines, only two are munged.

I can go with the replacement of only those which match the contents of the To: line, but that's not the way I read your 'previous statement' ....???? Your word "regardless" is the catch.

I had made the assumption (though thinking it was wrong) that you only saw the munged copy because I didn't see your specific remarks that stated that the contents of the lines in question were in fact different.

Link to comment
Share on other sites

OK, see in the second report how it says my name in the subject? That was munged with an 'x' in the first report I posted and is the address before the '[at]' symbol in my email address. That's the discrepancy I noted... it munges that subject line somtimes, but not others.

I'm going to say that I have a suspicion that I know the answer, but I need to ask for some help off-line first. The largest problem for me (and the other Forum folks/users) is that we don't have the unrestricted access to the background data needed.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...