Jump to content

EstherD

Members
  • Posts

    14
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    Cambridge, MA

Recent Profile Visitors

614 profile views

EstherD's Achievements

Member

Member (2/6)

0

Reputation

  1. Recently I have been receiving many HUGE spams, comprising mostly random garbage, over 500 KB each. SpamCop takes 'em and truncates 'em to 50 KB. But it's unclear if I am being charged for the FULL 500 KB submitted, or just the 50 KB truncated version used to generate the report. Anyone know for certain which it is?
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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.
  7. 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?
×
×
  • Create New...