Jump to content

Which IP address should be listed?


hadaso

Recommended Posts

In this example (http://www.spamcop.net/sc?id=z760893335z11...4199783d769b1ez an email message is sent from a PC (notebook (80.178.38.166.adsl.012.net.il [80.178.38.166])) through an ISP's outgoing mail server (hector.inter.net.il [192.114.186.13]). The originating IP listed by SpamCop is the IP address of the sending PC (80.178.38.166). However, the recipient's server is receiving the message in an SMTP session from the mail server (IP address 192.114.186.13). If the originating IP gets listed and the receiving server is using the SpamCop BL to block or tag mail, the messages sent by this sender would not be blocked/tagged, because the receipient would see them coming from 192.114.186.13 and not from the listed IP (80.178.38.166).

Actually no one is going to benefit from the listing of the IP of the sending PC, because it doesn't send any email directly out. Everyone receives the email it sends through the ISP's server, so if reporting this spam this is to affect blocking of this sender, it should be the IP address of the ISP that gets the listing, the one that actually sends the spam out to the public internet, not the PC that doesn't send out (of course if it were a zombie sending directly out it would be different.)

This reasoning also aplies to webmail from webmail providers who record the IP address of the web browser used to upload the message to the webmail client. In this and in the first example the authenticated transfer from the email client to the service's outgoing mail server is irrelevant to blocking spam, and the only data that can be used to effectively block spam is the IP address of the server that actually uses unauthenticated SMTP to spit the spam out to the public internet (i.e., hands the message over to a party that might want to block spam sources).

Link to comment
Share on other sites

The focus of the SpamCop parsing and reporting engine is to locate the "source" o the spew. Mission accomplished here. See http://www.spamcop.net/w3m?action=checkblo...p=80.178.38.166 currently showing;

80.178.38.166 listed in bl.spamcop.net (127.0.0.2)

If there are no reports of ongoing objectionable email from this system it will be delisted automatically in approximately 1 hours.

Causes of listing

SpamCop users have reported system as a source of spam less than 10 times in the past week

Looking for potential administrative email addresses for 80.178.38.166:

cannot find an mx for 80.178.38.166.adsl.012.net.il

cannot find an mx for 178.38.166.adsl.012.net.il

cannot find an mx for 38.166.adsl.012.net.il

cannot find an mx for 166.adsl.012.net.il

cannot find an mx for adsl.012.net.il

84.95.1.220 is an mx ( 10 ) for 012.net.il

postmaster[at]012.net.il bounces (349 sent : 175 bounces)

Other hosts in this "neighborhood" with spam reports

80.178.38.69 80.178.38.220 80.178.38.226 80.178.38.232 80.178.38.234 80.178.38.250 80.178.39.39 80.178.39.91

What you are jumping over is that in reality, one would wish that the server you are pointing at would do something to identify and reject the incoming e-mail from the "rotten" system ....

more to the story but time isn't available right now ...

Link to comment
Share on other sites

If I understand hadaso's argument correctly this is 180 out from what is argued in the thread "Gmail's server blocked" where PROGAME complained that all of Gmail is blocked because of spam comming from "one" Gmail user.

Or did I miss something?

Link to comment
Share on other sites

Actually no one is going to benefit from the listing of the IP of the sending PC, because it doesn't send any email directly out.

27776[/snapback]

This is not completely true. While the normal use of a Bl only tests the connecting server, spamcop's webmail implementation actually tests every IP in the headers to determine whether to move a message to the held mail folder.

In youe example, the ISP's server is trusted not to be an open relay. If not, use of the relays.ordb.org BL would also have caught the message.

Possible relay: 192.114.186.13

192.114.186.13 not listed in relays.ordb.org.

192.114.186.13 has already been sent to relay testers

Link to comment
Share on other sites

Coming back a but later (in between delivering stuff .. it is Mom's day here) ...

If the owner of the "notebook computer" is actually "the spammer" .. then the notification to his/her ISP should (in the ideal world) halt the continuing flow of e-mail from that user.

If the "notebook computer" was a zomby, then it's hard to picture that the comtrolling spammer would only send one or two e-mails out from that system .. the 'norm' would be "take advantage while it's mine" and one would see a tremendous urilization of bandwidth being consumed from that connection ... yet another clue for the ISP providing connection to the user to get a bit excited ... (note SenderBase data for the first IP .. 0.0 .. hinting that the spam spew should have gained some attention) ... this spike may or may not be immediately recognized by the next ISP, but .... the point remains that the spew was originating from the "notebook computer" and the complaints would have been sent to that user's ISP .....

As far as the comparison to the GMail server thing, maybe I'm in too much of a hurry here, but ... I fail to see the 180 out as far a problem with the parser ... the GMail servers were getting listed because that's where the trail stopped .. if GMail was adding in proper header tracking to show where the connection was actually coming from, then the complaints would (normally) go to that user's ISP . just as in this case ... the only 180 out I see is the lack of headers from one ISP, actual data available in this case ...

Link to comment
Share on other sites

My point was this seems to be a no-win for SC. In this thread SC should not go as far as the data leads and stop at the ISP. In the Gmail thread the bitch was that SC only went as far as the ISP and not to the sender (no data past the ISP not with standing).

So SC went to far / should have gone farther. SC didn't report here / did report there.

Just the same old problem, never let users have access to a software tool, they will break it.

Link to comment
Share on other sites

I'm still confused. In this query, the offending "source of the e-mail" was found.

In the GMail situation, the "source of the e-mail" was NOT found, instead stopping at a GMail server, because the "real source" could not be tracked past the GMail serber. I have to be missing something ....

OP wants the "big" e-mail server to bit the SCBL .. this is not the intention of the SCBL ... (for a list that does go to this next level, see the FAQ, look for SPEWS ... noting once again SPEWS is not spelled SpamCop)

Link to comment
Share on other sites

My point was not that the IP used by the sending PC should not be reported to the ISP so they can deal with the spammer. It's useful info for them. Just that it is completely unuseful to include it in the statistics used to list/unlist in the blocking list, as almost anyone using the list to block spam (except probably only SpamCop email service) is testing the address used by the SMTP client conecting to their incoming SMTP server. So it is completely ineffective for blocking this spammer for almost anyone, and gives very little incentive for the ISP to get rid of the spammer. It has no effect on the listing staus of their mail servers. Actually, even if everyone were parsing their "received" headers to try to block according to the originating IP address and not the "last in chain", all it takes a spammer to avoid it is using DHCP to get a new IP address if there are "too many bounces".

Pinpointing the originating PC's IP address is very useful in the report sent to the ISP, but is not useful in the blocking list. It just provides ISPs with a tool to avoid listings for servers that really spit out tons of spam by getting SpamCop to list IP addresses that never send out any email. If spammers were be a little bit smarter, they could use the same technique to avoid listing of the addresses they use to send. So I think that the correct implementation should be to report to the ISP all the internal IP addresses used in sending the spam out, that they can use to locate the spammer inside their system, but in the list that is used by many ISPs to block incoming SMTP sessions (or tag mail coming from these sessions) either the address that sends the email out using SMTP should be listed, or no address at all.

Link to comment
Share on other sites

Maybe what my problem is, is that we talk about what SC should/shouldn't do and maybe what the discussion should be is about the philosophy of the how to control/filter spam.

If we don't agree on, understand, the basic concepts SC is trying to implement we will never agree on who and what should be reported except in grosses of terms.

Reading hadaso's last post it occures to me that there may be (is) a difference between what and who is reported to who and what address is added to a block list. These need not be the same. Reports can be sent to the PC sourse of the spew, his ISP/SMTP, and others that want reports of spam (ref threads about reporting to MicroSoft, ftc, FDA etc.). But the address of the SMTP (or the PC) is all that is added to the block list.

I don't have access to the SC's block list or the logic so I should shutup and spend more time reading.

Link to comment
Share on other sites

What ISPs need in a report is the path of IP addresses that the message passes until it leaves their network. If SpamCop reports this in a nice useful way then abuse team members learn to prefer handling spamcop reports first because they save them time, as opposed to reports form other sources that make them have to parse the headers themselves (if headers are provided!).

But what a user of the BL that sets an SMTP server to query SpamCop BL with the IP address of incoming SMTP sessions needs is just the last IP address in this chain. It is the only address that might connect to her server and send her spam. Letting ISPs get away with transfering listings to their (often large) pool of internal network addresses (I mean addresses they give to their connected users, or addresses of other ISPs in case of webmail) and keep their outgoing mailservers "clean" ("clean" from listing. Not from spam).

Link to comment
Share on other sites

IMHO, reports should be sent to both the webmail source and the connecting IP address so that both can stop that person from sending email. As I don't quite understand how it would be done, I don't know whether it is possible.

As I have said before, there are no 'innocents' any longer. There are ISPs who are shirking their responsibilities, there are incompetents who don't know how to read logs or configure servers (or they have made a mistake which, as soon as they get a report, they correct), and there are the totally ignorant who don't have anti-viral protection and aren't aware of how computers can be infected.

ISTM, that spamcop reports are clear enough to any competent abuse desk and that the only reason that anyone would ignore them is if the usual ones they get are 'reporter mistakes' (and, IMHO, it is irresponsible of them not to report the mistakes to spamcop). Even then, if the volume suddenly increases, then it would be a signal that, perhaps, there is a real problem.

Miss Betsy

Link to comment
Share on other sites

It appears that hadaso is advocating "punishing" the ISPs who smarthost for their spammers, by listing those ISPs' mailservers in some sort of blocklist or blacklist. That is not the function of the SCBL (the SpamCop Blocking List, a conservative list which is supposed to be about education and protection from current spam spewers, not punishment), but it does appear to be (at least partially) the function of SPEWS, Spamhaus, and perhaps others.

IIRC, past requests of this type were met with the standard refrain "too much collateral damage".

Link to comment
Share on other sites

It appears that hadaso is advocating "punishing" the ISPs who smarthost for their spammers, by listing those ISPs' mailservers in some sort of blocklist or blacklist...

27795[/snapback]

I am not advocating the punishing of anyoen. I just say that currently the SCBL is useless for blocking spam from almost big ISPs the way described here in the faq. Not in direct rejection and not in the preferable way of tagging spam. For all big ISPs and most big webmail providers SpamCop lists IP addresses that will never send spam ito a recipient (I'm not refering here to listing based on reports about spam sent directly and not through an ISP's mail server). SpamCop is just allowing those ISPs to dillute the BL by listing IPs that no one will ever receive mail from, and at the same time it does not list the IP's from were the spam was received by the recipients that reported it. At the same time SpamCop advocates that services such as Gmail that only list the Received headers required by RFC821 (or 2821) should list an additional Received line that corresponds to internal transfer of info (input to a web application in Gmail's case) just to avoid the real server from being listed, so that if anyone uses SCBL to reject or tag spam, it would not reject any email from Gmail as only IP addresses of machines used for "internal" communications would be listed, never the IP addresses of the server that hands the spam over (here "internal" communications between the web browser acting as an i/o device of the web application and the host hosting the web application).
Link to comment
Share on other sites

Guidance from above received. Words are shared thusly;

Date: Mon, 09 May 2005 10:43:52 -0600

To: "Wazoo"

From: SpamCop Admin

Subject: Re: BL target selection

You're not confused. GMail is an exception because they don't record the

source IP in their headers. Our parse is always going to tag their mail

server as the source.

SpamCop policy is to go after the source IP, not the main mail server or

smarthost. We often, but not always, send a 'relay' report to the host of

the main mail server.

The policy is not going to change. Nothing keeping any ISP using our

service from testing every IP in the headers just like Cesmail does.

Compromised user machines routinely send spam directly because the spammer

uses his own SMTP engine to send the mail. ISPs who only test the

connecting IP will be able to block that traffic.

You have my permission to post this.

- Don -

>http://forum.spamcop.net/forums/index.php?showtopic=4138

>I'm not doing well here. Argument is that an 'upstream' IP

>should be the target of the Complaint/Report/BL inclusion.

>One user is comparing this scenario to the results of the BL

>inclusion of some GMail servers (massive discussion) ...

>

>My explanation that the GMail servers got listed because that's

>where the tracking stops, whereas the above item did track the

>e-mail to the source, so that's what was targeted doesn't seem

>to be flying. In the off chance that I'm having an even worse

>day than you're hinting at, am I that confused?

>

>GMail server on the BL

>http://forum.spamcop.net/forums/index.php?showtopic=3973

Link to comment
Share on other sites

Guidance from above received.  Words are shared thusly;

Date: Mon, 09 May 2005 10:43:52 -0600

To: "Wazoo"

From: SpamCop Admin

...  GMail is an exception because they don't record the

source IP in their headers.

27808[/snapback]

What does "Gmail is an exception mean here? Does it mean that they will end up more often on the BL or does it mean that SpamCop takes into account their different policy and scores them a bit differently to compensate for Gmail's policy??

...

SpamCop policy is to go after the source IP, not the main mail server ...

...  Nothing keeping any ISP using our service from testing every IP in the headers just like Cesmail does.

27808[/snapback]

Nothing is keeping them except ignorance. There's no hint about this being needed in the faq. Cesmail is not mentioned in the faq. A typical mail admin or just email user using filtering software usually configures the software to test the incoming session IP against several BLs, and there's nothing in the SpamCop BL hinting that this is not the best way to do it with SpamCop BL. The intructions that are included in the faq are for testing the IP of the incoming session for SCBL listing. The description of how the process of listing works doesn't mention anywhere that SpamCop tries to go as far back as is possible to do reliably in the transmission chain. The examples given in the faq on what might be listed sugggest the contrary
"The sending system can be a direct email source (such as a site's primary mail server) or an indirect source (such as an open proxy or open relay that has been abused to send spam)."
Link to comment
Share on other sites

<snip>

Nothing is keeping them except ignorance. There's no hint about this being needed in the faq. Cesmail is not mentioned in the faq. A typical mail admin or just email user using filtering software usually configures the software to test the incoming session IP against several BLs, and there's nothing in the SpamCop BL hinting that this is not the best way to do it with SpamCop BL. The intructions that are included in the faq are for testing the IP of the incoming session for SCBL listing. The description of how the process of listing works doesn't mention anywhere that SpamCop tries to go as far back as is possible to do reliably in the transmission chain. The examples given in the faq on what might be listed sugggest the contrary

27815[/snapback]

...This seems to come pretty close, though: SpamCop FAQ: What is the SpamCop Blocking List (SCBL)?, especially the first paragraphy under the heading, "How the SCBL Works," which you quoted correctly, including "or an indirect source (such as an open proxy or open relay that has been abused to send spam)" which I would interpret as including a non-server that is functioning as an SMTP server.
Link to comment
Share on other sites

hadaso,

You seem to think this is a big problem. I personally do not see that much spam being legally relayed through ISP's.

You are right, the spam you posted would not get blocked by a simple "connecting IP" check using only the SCBL, but how much of your spam is actually showing this characteristic?

There are other tools which can (should) be used as well, including many other BL's. Even the spam you posted seemed to be trapped by spamassassin rather than any BL. In my experience, very few implementations doing much good are using only one BL. Most have multiple levels of BL's (including local) and usually implement SA or something similar as well.

What does "Gmail is an exception mean here?

From the previous discussion of GMails problems, they will end up on the BL more often because their headers do not point to the real source of the problem. In your terms, that seems to be a good thing.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...