Jump to content

EstherD

Members
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral

About EstherD

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  • Location
    Cambridge, MA
  1. EstherD

    re. @devnull.spamcop.net

    Hopefully I am NOT the one everyone seems to be waiting on to supply "the outcome of the intervening discussion"? If you are, then please be advised: Not going to happen. Because I was NOT advocating either for or against ANY particular "outcome". Simply reporting the facts as I see them, and nothing but the facts, so that: • Someone wouldn't get the clever idea that they could bypass the /dev/null assigned by the parser by plugging the unmunged reporting addr into the "user notice" field. • Some other one(s) wouldn't be surprised (as I was) when, after spending far too much time finding a suitable reporting addr, SpamCop promptly routed my "user notice" to /dev/null. IOW, I'm OK with the current outcomes. Just wish they had been documented somewhere. Would have saved me some consternation I didn't need.
  2. EstherD

    re. @devnull.spamcop.net

    There's a Catch 22 in the use of the "User Notification" that you should be aware of: If the recipient addr you specify in the "User Notification" field is one that SpamCop routinely sends to /dev/null, then SpamCop will NOT send a user report to said addr as requested, but will instead /dev/null your user report, just as it would with any parser-generated report for said addr. Three implications: • Taking a cleaned-up /dev/null addr from the parse and sticking it into the "User Notification" field will NOT cause a user report to be sent to that addr. Your user report will also get sent to /dev/null, just like the parser report. • The reporting addr you find through your own research, e.g. via whois, will NOT cause a user report to be sent IF SpamCop normally /dev/nulls the addr you specify. • You cannot know in advance if the user report addr you supply is clean or not. It only becomes clear after you hit submit and look at the submission results.
  3. No, that won't help. You must have been an early adopter of Apple mail. Therefore, like me, you have an old user@mac.com acct. Because of the way Apple has transitioned those old accts over the years, an old user@mac.com acct can also receive email for user@me.com and user@icloud.com. However, not everyone using Apple mail has an old user@mac.com acct. Those who joined later got an acct that only receives mail for user@me.com and user@icloud.com. And those who joined later still got an acct that only receives mail for user@icloud.com. None of those more-recently registered accts can receive mail for user@mac.com. It's the fact that you have an old user@mac.com acct that seems to be causing the problem, not how you are accessing your acct. The funny new headers seem to appear only for users who have one of those old user@mac.com accts. And it doesn't matter which of the three valid forms of AppleID you use to access the msgs. You will still get the weird new headers. However, if you had one of the newer accts that only receive email for user@me.com or user@icloud.com, and cannot receive email for user@mac.com, then you would not have this problem. At least, that's how it appears to me. I have both types of accts: an old some_name@mac.com acct and a separate, newer another_name@me.com acct, which cannot receive email for another_name@mac.com. The weird new headers appear only on my old some_name@mac.com acct. They do not appear on my newer another_name@me.com acct. At least, not yet.
  4. The following describes a work-around for this problem. I have used this work-around successfully on a dozen or so spams in the last couple of weeks. If the headers of your message look like this: Then MODIFY the headers BEFORE you submit the spam, by DELETING the FIRST TWO "Received from" header lines, so the headers like this: FWIW, this problem seems ONLY to affect the headers on my user@mac.com emails. My user@me.com emails still have headers that can be parsed correctly w/o ANY modifications. HTH... -- EstherD
  5. Yes. I've been successfully submitting spam from that email acct for years. Until this week. Here's a recent example of a good parse: https://www.spamcop.net/sc?id=z6530672892z4c7f3ceb0ef8bac0115a080c8071850fz Yes. Have several mailhosts configured. All were configured several years ago. Only receiving spam on the Apple acct currently, so it's the ONLY one that's been exercised recently. Thought about deleting / reconfiguring the Apple mailhost entry, but decided against, because that particular mailhost entry had to be "hand-crafted" by SpamCop in order to work correctly. Know we're NOT supposed to alter the email in any way, but I decided to try deleting the wacko headers and resubmitting. Msg parses and reports seem reasonable: https://www.spamcop.net/sc?id=z6532443911zae1d5cd307cf1798d33f14830ad6975az Don't get many spams on that Apple acct. Only a couple a week. So maybe I'll just clean 'em a bit up before I submit 'em. Oh, and FWIW... The transition, if there is one, is apparently not complete. I have several other Apple / iCloud email accts. Msgs received on those accts do NOT have those wacko headers (yet). Alternatively, it may be because the acct with the odd headers is really old -- a user@mac.com acct.
  6. Sometime in the past week Apple / iCloud made a significant, probably permanent, change to the format of the headers generated by their mailservers. Consequently, messages no longer parse correctly. Here's an example: https://www.spamcop.net/sc?id=z6532255867z0d3753ed97e2c960ff2fa2e6c4de3abez Can anything be done to remedy this problem?
  7. EstherD

    flood control

    [at]Lking - Rereading my post today, it does seem a bit harsh. Not my intent. Sorry. Apology accepted and apology given. Call it even, OK? [at]Farelf - Thanks for the info. Not advocating for a change, especially since I don't know exactly what bad behavior(s) search flood control is designed to mitigate. Just wanted to better understand what's happening. That said, a 20 sec wait is no big deal when you get a couple of hits, because it will take at least that long to process 'em. But it DOES seem a tad long to wait when your search comes up completely dry.
  8. EstherD

    flood control

    Thank you, Steve. I suspected it might be something like that. -- EstherD
  9. EstherD

    flood control

    You didn't read my post CAREFULLY. I wrote "Is "flood control" (on a search)..." Which obviously means I experienced "flood control" while doing a SEARCH, NOT while posting. The EVIDENCE is a error message that appears at the top of the search results whenever I do two searches in quick succession, e.g. less than 8-10 seconds apart: Flood control is enabled. Please wait at least 10 seconds before attempting to search again. Something I'm quite likely to do whenever the first query returns no results... I IMMEDIATELY modify (or change) the keyword(s) and resubmit. So I've seen it FREQUENTLY these past two days. Which is why I'm asking. Doesn't seem to matter whether I use the search bar at the top of the page or the advanced search page. BOTH exhibit similar behavior, although the wait time DOES seem to vary randomly. Don't believe me? Try it yourself. [ Although, if it IS a "newbie-only" feature, then of course you WON'T see it. But then neither will I, at least not much longer, assuming I keep posting at this rate. ]
  10. EstherD

    flood control

    Is "flood control" (on a search) something that is enabled ONLY for newbies like me? Or does it apply to everyone, all the time? Note: I understand WHY a feature like "flood control" might be needed, especially on a high-profile target forum like SpamCop, so please don't lecture me about that. I'm just curious whether "flood control" is something I need to endure only for a limited time (i.e. while I'm still classed as a "newbie"), or whether it's a permanent feature for ALL users of this forum. (Not answered in Help or any of the FAQs, which is why I'm asking here.)
  11. Steve -- On many other fora, marking a thread as "resolved" is typically the prerogative of the OP, and there's usually a button provided for that purpose. Couldn't find one here, nor could I find any info about how to mark a thread as resolved in any of the FAQs. Surmised that it might be handled by the Admins, and it looks like it is. So thanks for marking this thread "resolved".
  12. OK. So late yesterday I emailed both the SpamCop Deputies and Don. Today I got an email from Don granting me a "Mailhost waiver". Dunno what that might be, but the parser no longer flags Apple as the source of the spam, but looks deeper into the message to find the REAL sender. So it looks like I'm good to go. Thanks to all for your assistance. Community is GOOD! (FWIW, the abuser in the spam I was trying to process yesterday is one of those dratted "reports disabled" ISPs. So I had to submit a report manually, which kinda negated the whole idea of using SpamCop to automate the process. Especially given the time/effort required to setup my acct. So it goes...)
  13. Persistent (repeatable) error during mailhost configuration for my acct at me.com (AKA mac.com AKA icloud.com): Host ms08542.mac.com (checking ip) IP not found ; ms08542.mac.com discarded as fake. Sorry, SpamCop has encountered errors: The email sample you submitted for REDACTED[at]me.com appears to traverse more than one domain. Please ensure that you configure each mailhost individually and in order. Proceed here: <https://www.spamcop.net/mcgi?mhc2=REDACTED> Problem appears to be in the FIRST "Received:" header line that mailhosts is looking at, to wit: Return-path: <service[at]admin.spamcop.net> Received: from nk11p00mm-smtpin010.mac.com ([17.158.160.105]) by ms08542.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTP id <0ND600G7ESMQ9WH0[at]ms08542.mac.com> for REDACTED[at]me.com; Thu, 09 Oct 2014 17:01:38 +0000 (GMT) Original-recipient: rfc822;REDACTED[at]me.com Received: from prod-sc-www1.spamcop.net ([184.94.240.112]) by nk11p00mm-smtpin010.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with SMTP id <0ND600368SMNFN00[at]nk11p00mm-smtpin010.mac.com> for REDACTED[at]me.com (ORCPT REDACTED[at]me.com); Thu, 09 Oct 2014 17:01:38 +0000 (GMT) Mailhosts appears to be looking at an INTERNAL TRANSFER among Apple's mailservers. And Apple (in its infinite wisdom) is NOT publishing a valid DNS A record for said host ms08542.mac.com (returns NXDOMAIN). The SECOND "Received:" header line line looks OK, however. So what do I do now?! [ To add insult to injury, the provided link at the end of the error msg is NOT live, and if pasted into the browser address bar leads to a TOTALLY BLANK PAGE. (I have redacted the link, since I think it may reference dynamic content related to my PII.) ]
×