hadaso Posted May 8, 2005 Share Posted May 8, 2005 In this example (http://www.spamcop.net/sc?id=z760893335z11...4199783d769b1ez an email message is sent from a PC (notebook (18.104.22.168.adsl.012.net.il [22.214.171.124])) through an ISP's outgoing mail server (hector.inter.net.il [126.96.36.199]). The originating IP listed by SpamCop is the IP address of the sending PC (188.8.131.52). However, the recipient's server is receiving the message in an SMTP session from the mail server (IP address 184.108.40.206). 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 220.127.116.11 and not from the listed IP (18.104.22.168). 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 More sharing options...
This topic is now archived and is closed to further replies.