Jump to content

PeterJ

Membera
  • Content Count

    109
  • Joined

  • Last visited

Everything posted by PeterJ

  1. PeterJ

    Paypal Phish

    In retrospect the following items should have pointed me to knowing it was not a real email: 1) My name was not used in the email. PayPal states that they will address you by your name at the beginning of any correspondence. 2) There was a bogus received line that I never noticed before: 3) Korea server 4) the correct address to report PayPal spoofs to is <spoof[at]paypal.com>, while the fake email states it is <fraud_alert[at]paypal.com> Maybe that will turn this thread into something slightly more useful. *still embarrassed*
  2. PeterJ

    Paypal Phish

    Yipes! I did click on a link, but see what is going on now. Wow, I really did not know that the Phishing attempts were this good looking. Here is what occured (and still occurs) when I click on the link: Two instances of FireFox open, one page with PayPal that explained the web page desired does not exist and another page with address: https://61.33.168.151/? that was completely blank. Upon further inspection FireFox blocked the popup that the latter page was trying to load. So no harm done, but I guess I can blush for not knowing how good the phishing mail looks. I really have not received much and never imitating PayPal before (although I knew it existed). I will send a copy off to PayPals spoof reporting address for the hell of it. Can someone please change the title of this thread to Paypal Phish instead of PayPal blocklisted. *blushing*
  3. PeterJ

    Paypal Phish

    Now I am having doubts...is the message a phishing attempt or real?
  4. Thanks Steve. Your information is most useful. I just wanted to clarify that I never mentioned being on the spamcop block list, only on DSBL. I think I will hold on to this IP address for a while and see if I can make it "good" again. I already submitted the address for removal at DSBL. The main question I wanted answered was whether or not SpamCop checks *every* IP address on received mail. I will either adjust my blocklist settings for SpamCop mail or get a different dynamic IP to solve the issue when I need/want to. I suppose I could complain to SBC Yahoo that I received a tainted IP, but I am not sure that this is useful. But just in case, does anyone have an open letter to broadband providers regarding stopping open proxy abuse on their network? I ask this because I do not pretend that SBC is innocent and I am a customer so theoretically could apply pressure; especially as renewal time approaches... Hopefully...only if the ISPs do something about it.
  5. I am a SpamCop mail user. I have some questions regarding how SpamCop handles incoming mail as my IP is currently on DSBL. Here are the headers from a message I sent to my wife a couple days ago to help illustrate my question: (EDIT: I forgot to mention that my wife also has a SpamCop mail account, so this sample message was sent from my Windows mail client using our ISPs SMTP server and received by her SC mail account) First I understand that I can simply force my broadband modem to get a new IP address, but for now I want to keep this slightly poisoned IP so that I might understand better. I use SBC Yahoo for a DSL connection and my IP for now is 67.36.58.194. I did upgrade my firmware on my router recently, so I probably got a new IP after that. I read here and elsewhere that many people do not accept mail from dynamic IPs (of course), therefore one with a dynamic IP should send mail via their ISP. Well this is where I am a little confused because the above sample is a mail that I sent via SBC Yahoo's SMTP server, so why would SpamCop hold the above mail? Does SpamCop test every IP in the headers when considering what to hold? Is there a similar and parallel process to the "mailhosts" implementation for reporting, perhaps behind the scenes, for incoming mail? Or maybe the mailhosts data is utilized by the parsing process on incoming mail... It seems to me that SpamCop could simply recognize that the email came from a legitimate SMTP server (66.163.168.181) and continue without testing my actual IP address. Thinking aloud: Is the reason this will not work because although many spammers are using open proxies now, some are still using throwaway dial up accounts and actually sending through the ISPs SMTP instead of direct to MX? As this whole open proxy thing continues to blow up, it seems to me that pollution of dyamic IP pools is going to continue to get worse. Does anyone know if spammers are using "thowaway" broadband accounts? It can't be cheap enough for this yet, can it? Ok, someone bring me up to speed on this please.
  6. PeterJ

    Hotmail

    I have a Yahoo account, but it is set to forward to my spamcop account. I have the SpamGuard (or whatever they call it) turned off so that all mail received by this yahoo address comes to my SpamCop account. I do no reporting using yahoo's tools. Are you trying to find a happy medium between POPing mail from these external accounts while still being able to benefit from their built in spam detection and reporting systems?
  7. PeterJ

    spamcop encountered problems

    I have seen this issue repeatedly when quick reporting small amounts of spam (5 to 30) from the SpamCop webmail interface, however it remains intermittent as previously mentioned. I have seen no correlation with the number of spam I submit and the occurence of the error. Since Monster has received the same error when forwarding perhaps this can help shed some light: If it occurs every time you submit then it is probably more likely a config issue with your mail client, if it is intermittent, then perhaps it is indeed the same issue we are seeing in SpamCop webmail. I noticed recently in a PopFile forum that some people using an extension that allows for reporting to SpamCop were receiving the same error message via forwarding, but again, perhaps this is a configuration issue on their end. Thread here: http://sourceforge.net/forum/forum.php?thr...forum_id=226152 SteveUnderwood wrote: To back up what Steve wrote above, I am seeing the following when the issue occurs in webmail: A failure message received for each spam message I quick reported. My held mail messages remain in the held mail folder. After hitting the confirmation I have noticed that Horde IMP switches my view to the Inbox every time instead of remaining in the Held Mail folder. As with Steve, if I report again, they will go through (although I am in the habit of deleting them, to eliminate any possiblity of double reporting.)
  8. PeterJ

    Turba and LDAP

    I have been reading up on Horde recently and noticed that Turba can utilize LDAP. Turba is Horde's 'address book' component, http://www.horde.org/turba/ , and since we use Turba as part of SpamCop's webmail system I could not help but dream... It would be a really cool enhancement if SpamCop used LDAP as the backend for our addressbooks. This could allow users to access their addresses via a client that supports LDAP. In this regard IMAP and LDAP would be a pretty good pairing for keeping data the same whether one uses a mail client or webmail for access. Although LDAP has been traditionally used for 'global address book' or 'shared addressbook' situations, it is possible (from what I have read) to implement individual address books including authentication to access them. Just a thought in case it is feasible given money, time, etc.
  9. PeterJ

    Turba and LDAP

    Please take no offense. I really was not sure that you had asked him from the words that you used. Also I did not know that you and JT were in direct communication regarding threads in this forum, but I just today noticed at least one other thread where you provided an answer from JT; so now I am aware of this occurring.
  10. PeterJ

    Turba and LDAP

    Are you saying that you asked JT this question? For reference on this topic the following large PDF file (500 pages) has a section on LDAP and Turba at pages 355-364; ftp://kalamazoolinux.org/pub/pdf/ldapv3.pdf
  11. PeterJ

    Turba and LDAP

    I guess someone decided to move this from "SpamCop email" to the Lounge. In case JT ever reads this...could you comment on SpamCop's current backend for our Turba addressbooks? I assume it is SQL of some variety.
  12. Did the SpamCop parser determine the source to be 207.126.97.64 or 67.15.24.51? 67.15.24.51 is listed and the sample given matches your subject regarding Osama: http://www.spamcop.net/w3m?action=checkblock&ip=67.15.24.51
  13. PeterJ

    spamcop encountered problems

    To clarify. I am seeing as Don describes and since JT is aware of the issue I thought I would simply indicate that I experienced this specific issue today. Note that this issue is intermittent. I have noticed no correlation with the types of spam, concurrent use of IMAP client, amount of spam, etc. with the errors. I do not know how to duplicate the issue. It occurs rarely for me, today is the first time I have seen it in at least several weeks.
  14. PeterJ

    spamcop encountered problems

    FYI this is still occurring. This morning I received around 30 of these error messages after quick reporting from the webmail interface. Subject: SpamCop Encountered Errors Sender: SpamCop Autoresponder
  15. I am seeing the same thing as Larry. Here is an example where the parsing determined the source correctly; the only thing out of the ordinary is that where it shows "SBC" it should say "SpamCop" instead. This email was received directly by my spamcop email address, it did not have anything to do with SBC, however SBC is the name of one of my mailhosts that I have setup. http://www.spamcop.net/sc?id=z414008752za9...cfd9d25ebd8743z
  16. Can someone take a quick look at this, is it an example of too much trust by the mailhost system? http://www.spamcop.net/sc?id=z409328054zb8...b07c89d581a600z I do have an Ameritech email address, however this piece of spam was received directly by my spamcop address. I am not quite sure why it trusted the ppp-68-251-42-210.dsl.chcgil.ameritech.net... I suppose I could list my mailhosts that I have set up, but they are very long. Thanks.
  17. PeterJ

    New SpamAssassin rules

    JT -- You probably already know, but Chris Santerre has created a new custom rules website located here: http://www.rulesemporium.com/ Also, I have read recently that the anti-drug rule has had several improvements added to it, following snipped from Matt Kettler regarding version 0.60: There are more changes but I think this one alone warrants updating to the 0.60 version of antidrug. Can you comment on whether or not rules dujour is implemented for SpamCop's SA implementation to automatically update our custon rules? (Here: http://sandgnat.com/rdj/rules_du_jour)
  18. Jeff Chan recently posted an announcement regarding SURBL to the SpamAssassin general mailing list for those who might be interested: http://thread.gmane.org/gmane.mail.spam.sp...n.general/46349 If JT reads this, any chance of trying this with SpamCop's SpamAssassin setup?
  19. Can anyone explain more about the parser's conclusion here: http://www.spamcop.net/sc?id=z396488127z33...c1721d7fcda912z It is not very complicated, but I have never seen the following message before: It seems to me the source of the mail is the dsl connection at 64.170.197.83 (which is on the SCBL.) The parser identified 64.164.98.8 instead. I did notice that 64.164.98.8 is listed in SORBS for sending to spamtraps...
  20. PeterJ

    SpamAssassin and Communigate

    Sure I can read... , sorry about that. Ok, if CommuniGate trial software is not widely used by spammers (at least from the "SpamCop email" perspective) maybe JT would turn off this test or at least consider lowering the score. I doubt it would matter much if he scored it at .75 or, find out how long until your forwarding service will purchase CommuniGate or switch to a different product, certainly "trial" indicates a temporary situation, no?
  21. PeterJ

    SpamAssassin and Communigate

    Maybe this helps...on the SA site regarding rules, http://spamassassin.org/tests.html, it states the following regarding the COMMUNIGATE rule: "Sent using a trial version of CommuniGate" Perhaps there is an error with this test or perhaps a trial version of CommuniGate is in use and the test is accurate.
  22. Assuming that this still is the case, then the response goes to a deputy who approves of the whitelisting presumably?
  23. Perhaps Duh... I just realized that the OP of this topic is "jeffc" perhaps Jeff Chan? If so and you come back to this thread, have you ever spoken with Julian regarding SURBL? Just curious if it has been given any thumbs up, ignored, or whatever....
  24. I found an interesting discussion in the SpamAssassin developers mailing list inlcuding Jeff Chan and others on SA, SURBL, and URIDNSBL: http://thread.gmane.org/gmane.mail.spam.sp...sin.devel/23334 Two other very small threads: http://thread.gmane.org/gmane.mail.spam.sp...sin.devel/23456 http://thread.gmane.org/gmane.mail.spam.sp...sin.devel/23452 After reading this stuff I have a clearer picture of what is going on and I am curious about the whitelisting. Jeff Chan is using whitelists for domains with his implementation of SURBL, but I am more curious about what happens on the SpamCop side with whitelisting of domains. Miss Betsy wrote: Miss Betsy or others -- Do you know more about the process that SpamCop uses to whitelist IB domains that are reported from URLs? Do deputies regularly do this? In one of the short threads linked aobve Jeff Chan states: Given that whitelisting is occuring both on SpamCop's side and also on SURBL's side of things hopefully FPs will remain low with this concept. Also given that this is meant to be plugged into SA, if one were to get a hit on this test, it ALONE would not result in the message being determined as spam. Eric -- In your current use of the spamcopuri plugin you created for SA can you comment on what kind of scores you are attributing to a a messsage based on spammy URL hits and how they relate to the threshold you are using to block/filter?
  25. SpamCop does not supply a database of "spammy" URLs for people to directly access, however at least a few people have been scraping this data from http://www.spamcop.net/w3m?action=inprogress&type=www. I personally do not have a problem with this for now, but I do think that SpamCop will need to address it in the future if it becomes more common. As far as I know there are two implementations that are retrieving reported SpamCop URL data in some manner: 1) Eric Kolve's spamcopuri (who has posted earlier in this conversation) 2) SURBL -- spam URI Realtime Blocklist (I do not know who is behind this, but this link and the one in my previous post mention Jeff Chan at the bottom of each page) Both of these can integrate with spam Assassin. I doubt many (if any) are using the SpamCop URL data at this point, the SURBL stuff mentions "proof of concept." Does SpamCop Administration have a position on this I wonder? Eric Kolve -- Care to jump back in for more discussion of this? Have you ever spoken with any SpamCop admins regarding this?
×