Jump to content

lawless

Members
  • Content Count

    25
  • Joined

  • Last visited

Everything posted by lawless

  1. I haven't seen anything from the deputies or Julian on mailhosts since it was introduced in the spring. How is the beta looking? Will mailhosts be required for reporting anytime soon? I was under the impression that the innocent bystander problem from forged "Received: From" headers was cause for an aggressive roll-out. Or is the mailhosts database now good enough that reports from unconfigured users can make use of the mailhosts DB for establishing the trusted relay chain?
  2. lawless

    SPF Rocks!

    Turns out a nifty default rule can be established: "v=spf1 a/24 mx/24 ptr -all". This ACL works for about 80% of legitimate senders. I've configured SPF to apply this rule whenver an explicit SPF rule is absent. I've hand-coded 'fallback' records for the few critical correspondents that don't fit the above. I've even modified the 'Mail::SPF::Query' Perl module to convert "?all" "~all" and "+all" into "-all". This was because I got spammed by someone spoofing an Earthlink address and their record specifies "?all" at the end. The most complex fallback and override records I've had to write were so SpamCop staff can send me e-mail in response to my occasional direct query. Anyone else sending me mail with an "[at]spamcop.net" envelope sender will get bounced though (incuding myself). JT should consider establishing a DNS server that validates SpamCop senders by their account name (via SPF's "exists" construct) rather than using the "v=spf1 ?all" that he has published. I've also created (modified someone else's actually) an 'access.db' whitelist capability that lets me whitelist a handful of people I know who send me mail from SPF-broken places like sbcglobal.com (hosted by yahoo.com). It's been extremely satisfying sitting here for the last two days watching spam getting constantly bounced in my 'sendmail' log window. David
  3. lawless

    SPF Rocks!

    I just deployed SPF on my MTA. It was quite a lot of effort, but it's blocking *all* spam. After about six months or so spammers will start publishing SPF records and RHSBLs will become necessary (I may go with a RHSWL myself). For the moment however, the results are spectacular! My experience and the customizations I made can be found at http://archives.listbox.com/spf-discuss/current for those who might be interested.
  4. lawless

    Forum configuration

    Recommendations: 1) Create a category dedicated to the reporting side of SpamCop. 2) Create a high-density headline display similar to what NNTP viewers show. These web-forums have *way* too much white-space. They are difficult to peruse.
  5. I've been paying attention lately to the SPF (Sender Policy Framework / Sender Permitted From) initiative. It's an excellent initiative and looks likely to be adopted. However it will be at least a year before it will be of much practical use, even if the world at-large embraces it. I won't explain how SPF works here. Please see http://spf.pobox.com for a full explanation. The following assumes the reader is familiar with the basics of SPF. It just occurred to me that the SpamCop webmail system could, with relative ease, adopt a SPF-like filtering capability quickly. I'm finding that despite the SCBL and SpamAssassin, much spam still sneaks through. SpamAssassin 2.70 (SA270) will support SPF (webmail currently uses version 2.63). 99% of the "escaped" spam I see would fail a SPF-like filter test. I'm hoping that JT would consider implementing a SPF-like filter capability for the webmail system in advance of the SA270 implementation. The SA270 implementation will benefit from (or perhaps even demand something like) this, so the effort would not be wasted. The suggestion is to have either SC or SC-webmail add a header that contains the transfer relay domain as determined by the first (or gateway) mailhost matched from each user's mailhost list. I suggest something along the lines of "X-SC-Transfer-Domain:". The gateway mailhost is trusted and so any reverse-DNS information provided by it in the "Received: from" header presumably can also be trusted. This relay nominally should be the outbound relay of most valid senders' traffic. To complete the enchantment, the webmail system would be modified to allow e-mail with a mismatched "Return-Path:" (i.e. "envelope sender") and "X-SC-Transfer-Domain:" to be held in a quasi-SPF "purgatory" webmailbox. This mailbox would be separate from the current "held" mailbox because the quasi-SPF filtering mechanism would fail for some valid e-mail. The quantity of mail appearing in SPF purgatory will be small, and will have a relatively high probability of being from a valid sender--thus suggesting a closer and more careful review process. The key element to understand for those inclined to comment is that SPF revolves around the "envelope sender" indicated by the SMTP "MAIL FROM:" protocol handshake rather than the "From:" header embedded in most messages. Please try to grasp what this is before commenting. See RFC 2821 http://www.apps.ietf.org/rfc/rfc2821.html.
  6. lawless

    New Look Browser Issues

    For older browsers and those like to disable CSS, the new reporting system pages are annoying because the reporting section appears "below the fold" and requires scrolling. Using TABLE instead of DIV would solve this. However, if that idea isn't deemed desirable, could the "Site Search" and "Site Style" DIV sections be moved down to the end of the HTML? Then when CSS is disabled, the navigation bar and the reporting sections will appear at the top of the page.
  7. lawless

    "new look" not looking good

    Julian, One final thought: Looking at the HTML, it seems that the left-side navigation bar is demarcated with <DIV> tags. Could the different horizontal elements of the pages be arranged using <TABLE> tags? I think this would make the page look good even for non-CSS browsers.
  8. lawless

    "new look" not looking good

    I use Opera 7.23 with the following 'opera6.ini' settings Note that the "[user Mode]" and "[Document Mode]" category labels appear to be reversed due to a bug in Opera. I run in "User Mode" (per the config pop-up, it's "Document Mode" in the ".INI" file) with CSS *disabled*. The config can be found under "Page Style->Configure Modes" in the ALT-P configuration dialog. This is the only way to prevent obnoxious background image files from intruding. However with CSS disabled, the new SpamCop "look", looks absolutely terrible! Simpler is better. I want the old simple screen back.
  9. lawless

    "new look" not looking good

    Regarding the forums: The "Lounge" where this was moved is supposed to be about stuff that has *nothing* to do with SpamCop--at least per it's description. Like I said, the new forum structure is stupid. In NNTP, I would have posted this under the top-level "spamcop" group, where all the reporting-side issues were traditionally posted.
  10. lawless

    "new look" not looking good

    Re the above comments: The new "web forums" suck and are badly structured. It makes no sense to me. The NNTP forums made sense and were *much* easier to use and navigate!!! Back to my post: I found this interesting link: http://www.rdrop.com/~half/Creations/Writi.../css.tip.2.html Julian, please add the "BODY ID" field described in here so I can create CSS overrides for SpamCop. I'll be upgrading to Opera 7.5, as they have added a bunch of new CSS features that should allow me to use Author CSS mode and User CSS mode and override the stuff I don't like.
  11. Ha! I fixed this one myself. I reluctantly setup my own MX a few months ago because my web-host provider kept getting their relays black-listed and this would cause SC to "hold" ALL my mail. Becoming a 'sendmail' expert was never high on my list, but now I've found some added benefit. It took awhile to decrypt the 'sendmail' documentation, but I finally figured out how to do something I've been wanting for some time: Substitute different envelope recipient addresses based on sender and incoming relay information. The main clue was figuring out that "Ruleset 0" rewrites the "envelope recipient" address. I've created a local ruleset (invoked by ruleset 0) that alters the envelope delivery address (not the "To:" field) if the sending relay is on a whitelist or if the envelope sender matches a different whitelist. The relay list covers the bulk of my high-priority correspondents since they are at large corporations that run their own mail relays and don't have spammers. The envelope sender whitelist covers a handful that have accounts at Yahoo! and like providers that are also sources of spam. Mail that doesn't match the whitelists gets sent to SpamCop to be filtered and then forwarded on to my regular POP accounts. I've reconfigured my screen 'biff' utility to monitor only the preferred sender mailboxes, so now I don't have my concentration broken all day long by idiot spammers. Only important business contacts get immediate attention. The added benefit is that my critical correspondents bypass SpamCop, so I won't get too badly hosed by the occasional SpamCop outages and slow-downs. For the adventurous, here's the ruleset. Don't bother telling me I should use a mailmap to translate my addresses instead of hard-coding them. I've only got two. Send me the correct rules instead if you think your smart.
  12. Also. . . Regarding SA270, my suggestion would not be obsoleted by its implementation because the SPF support in SA will still depend on wide-spread publication of SPF DNS "TXT" records. This will take a long time at best.
  13. Re-read my suggestion more carefully. A separate "purgatory" held mail box is a key component. This mailbox would accumulate a relatively small number of messages since the standard filters are applied first. False positives will occur, but they are held separately will be easy to identify. Those opting to use this feature will need to review the purgatory mailbox with an order-of-magnitude more care than the normal "held" mail. I bulk-submit my "held" mail with zero review all the time. The idea is to eliminate the last--very annoying--trickle of escaped spam at the acceptable cost of delaying the rare valid message where the envelope sender does not jive with the transfer relay's domain.
  14. Thanks for the reply JT. I've got it now. Also my mailhosts config is all setup and working fine now. Sorry I posted in the wrong place--I zipped past the "pinned" topics since they're usually old news. I'm finding the new web-forum a bit difficult. Liked NNTP much better. Could a the topics display be made much denser? There's much-too-much whitespace here.
  15. I've just successfully configured one of my accounts for Mailhosts. What I see seems like something I've asked for and apparently many others have as well: A way to white-list the inbound mail relays. What I don't understand is how Mailhosts will help SC detect forged Received: headers from implicating innocent relays. Here's the passage from the first configuration page: So how will the new approach prevent the first Received: header past the trusted chain from being a convincing forgery that implicates an innocent IP address?
  16. Ack! Never mind. The test messages got snagged by SpamAssassin and placed in "Held Mail." Should have checked this first.
  17. Successfully added the less active of my two working accounts to Mailhosts. Then tried the spam trap AT&T Worldnet account. The test e-mails (tried several) did not make it. However regular test messages sent to that account zip straight through. Doubled checked the AT&T settings to make sure their filters are all disabled and the forwarding to SpamCop is correct. All is well there. What's up?
  18. lawless

    New SpamAssassin rules

    My spam-free weekend was apparently a coincidence, as a flood ensued. This inspired a close review of SpamAssassin settings and the ratcheting down of thresholds to 4 for working accounts and 3 for the spam trap. Also looked up Jennifer, the author of ChickenPox, BlackHair, PopCorn and Weeds. Impressive! Anyone who can write regular expressions like that is a genius! http://www.emtinc.net/spamhammers.htm
  19. lawless

    New SpamAssassin rules

    JT, Thanks for pulling the RCVD_IN_BL_SPAMCOP_NET filter. The new SpamAssassin filters seem to be letting less spam through. I didn't do a careful message-level study, but the number that slipped through on my spamtrap account dropped from a handful a day to nearly zero. The weekend, which is usually especially bad, was especially good. I run the spamtrap account at threshold "4", and my normal accounts at "6".
  20. lawless

    New SpamAssassin rules

    I don't presently have a problem with the SCBL because of a laborious effort I made to create my own relay to prevent false-positives. See my earlier post in the NG "Harrowing. . ." However several SC users don't want to go to the trouble to create or find their own clean MXs, and they are susceptible to what I call "sudden total false positive syndrome." This happened to me. SC BLs your web-host provider's inbound MX, and suddenly ALL your e-mail gets blocked. Roy Lewallen posted in the old NNTP news group that he started getting all his e-mail blocked, and so removed the SCBL from his check-list. Then he also had to remove SpamAssassin due to the RCVD_IN_BL_SPAMCOP_NET tagging. He is clearly very annoyed. I want this removed because Julian favors aggression an experimentation over stability. I fully expect that he will get carried away sometime in the future and play havoc on my filtering. I want to be able to turn SCBL off when it gets out-of-hand while keeping SpamAssassin in the picture.
  21. lawless

    New SpamAssassin rules

    Actually I see that SpamAssassin has loads of these "RCVD_IN_" filters. Probably all of them should be disabled. At a minimum the ones that have explicits checks in the SpamCop mail system should. http://www.spamassassin.org/tests.html
  22. lawless

    New SpamAssassin rules

    The rule RCVD_IN_BL_SPAMCOP_NET is redundant and should be removed. Having it in SpamAssassin prevents users who want to run without the SpamCop block-list from making use of SpamAssassin. Those who get false positives from the SpamCop BL are forced to remove SpamAssassin from their configuration too. SpamAssassin and SpamCop BL have separate activations in the user configuration. RCVD_IN_BL_SPAMCOP_NET defeats this separation.
  23. Read my recent post "Harrowing (but Successful) False-Positive Solution Search" Chances are your ISPs inbound relay got tainted by outbound spam.
  24. I forgot to mention another significant issue. As soon as I discovered that Tierra has mail relays that get block-listed by SpamCop, I immediately setup my own outbound mail relay. I don't want spam-tainted relays at the web-hoster causing my e-mail to get blocked on its way past mail relays that subscribe to the SpamCop BL. If you have a static IP address and a Linux or UNIX system, setting up an outbound mail relay is relatively easy. Just make sure your inbound SMTP port is blocked by your router. Having a static IP is mainly about not inheriting an address recently used by a spammer via DHCP. I'm reasonably sure that none of 'sendmail', 'postfix' or 'qmail' run on Windows platforms, so you're stuck with Exchange if you want to relay from a Windows system. Don't ask me for help on that one. Since I had no success finding a web-host provider with clean relays, finding one with clean outbound relays is probably a near impossibility. EasyDNS doesn't allow outbound relaying. Good luck finding one if you're not prepared to setup your own. Configuring a clean two-way relay, as I finally did, is more difficult than setting up a outbound-only relay. It requires an "access" DB to permit the local systems to send mail out and "virtual domain" and "virtual user" tables to translate and forward inbound e-mail for just your domain while preventing abuse by spammers. I created a minimal 'sendmail' configuration that does this, and will share it with anyone who wants help. It's just a few lines, but it took a day to work it all out.
  25. I've just spent about three weeks finding the solution to an aggravating problem with SpamCop false-positives. I'm sharing the solution here to help others. If you're abruptly getting lots of false-positives, see the instructions below on how to check for a likely cause. I had always believed that SC traces e-mail as far back as possible using "Received:" headers, and then uses that farthest-back point for reporting the miscreant. This is essentially true, but over the years SC has become much less trusting of intermediate relays--apparently with good cause. Lately, with the explosion of spam, SC is seeing spam coming from a variety of ostensibly respectable sources. So I was quite surprised when suddenly ALL my e-mail from valid correspondents started getting tagged as spam. As it turns out, my web and e-mail hosting provider Tierra.NET has inbound mail relays that can be abused by spammers for sending outbound spam. Tierra is otherwise a great provider, but they appear to be idiots when it comes to spam control and prevention and relay management. They have web-host customers on their inbound mail-relay servers. Spammers sign-up for web-hosting accounts and then use 'perl' and PHP scripts to blast out huge volumes of spam. These get reported and the relays get block-listed. Then valid-source e-mail inbound to innocent bystanders gets marked as spam by SC. I figured all that I needed to do was change to another host provider who runs clean relays. A nice idea in theory--fuggedaboutit in practice. I tried iPowerWeb first. Their misconfigured 'qmail' relays produce SC-unparsable "Received:" lines, so after about two days my own reports got their relays SC block-listed. Then I tried ValueWeb. They're somewhat better, but they use the same bank of several dozen relays for inbound-forwarding and outbound mail. These relays get SC reports and are susceptible to sudden-total-false-positive syndrome. Their flat-out refusal to correct the problem and the very slow relays they operate convinced me to take the money-back guarantee. In the end, they all pretty much suck on the SC front. Tierra is the best host provider in my opinion, so I kept them. I wasn't ready to try out a fourth provider. Finally I found the solution. An outfit in Toronto, EasyDNS.COM, runs a squeaky-clean mail relay (aka MX). I registered the .NET variation of my .COM domain at my old provider and renamed my hosting account to .NET. At the same time I subscribed to EasyDNS and transferred my .COM DNS and e-mail forwarding to them. Then I established a mail-forwarding map with their web control-panel to forward most of my e-mail through SC and some of it directly to my newly named .NET hosting "shadow" account. If you choose to do this, here are some pit-falls: 1) Don't register your "shadow" domain at EasyDNS. If you do EasyDNS, creates a "parking" entry on their DNS servers that will prevent your "visible" domain from forwarding e-mail directly to your "shadow" domain. This happened to me. It required a manual configuration change by EasyDNS personnel to delete the "parking" DNS and mail-map entries (they are very competent). It's better to avoid this hassle. 2) EasyDNS's relay will reject your e-mail for a few minutes to a few hours when you switch your MX to them. You should edit your MX entries to make their server your secondary MX until their systems recognize your visible domain. This can be checked by configuring an alternate e-mail client personality that references their MX in the outbound SMTP field. Then send yourself an email periodically until they stop bouncing. Note that the EasyDNS relay will never accept e-mail to any destination other than your own account. 3) Watch out for the timing and dependencies of all the steps. It takes about 24-hours for a redirected 'whois' to take effect. I got away with little trouble because I had my .COM at ValueWeb by the time I decided to go with EasyDNS. The .NET register and rename was done on my old account while it was inactive. I haven't thought-through how to pull this off without the third provider. 4) Network Solutions' advanced-DNS sucks! If you are using this facility, transfer any domains you have registered with them to Tierra's DomainDicover before you proceed. When you redirect your 'whois' from (for example) ValueWeb to EasyDNS, Network Solutions deletes your DNS entry from their servers immediately. As a result your domain will be in "does not exist" limbo for twelve to eighteen hours. So that's my advice for anyone who hates SC false-positives and doesn't want to spend weeks digging around for a solution. If you want to check how good or bad your provider is, do this: 1) Run 'nslookup -type=MX yourdomain.com'. This can be done in a "command prompt" window on Windows NT, 2000 & XP. Here's a web-page that does the same thing for those who are afraid of a DOS prompt: http://www.zoneedit.com/lookup.html. 2) Enter the raw IP for each of the MXs listed in SC's block-list checker at http://mailsc.spamcop.net/bl.shtml. If any of the relays have recent reports or recent "spam trap" activity, you are at risk. If one is block-listed, you are already screwed. Older report samples are shown at the bottom of the page. If any occurred within the last month or two, you should ask your ISP to explain it. If you get a brain-dead answer, start worrying. Finally I should mention that another approach exists for the hard-headed and technically astute. You can setup your own MX while making sure that it's not an open relay. This is not for the faint-of-heart. Don't try it unless you know what you are doing or are willing to spend a few days beating your head against the wall learning. Mine is still sore.
×