Jump to content

lawless

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0 Neutral

About lawless

  • Rank
    Member
  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. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  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. Ack! Never mind. The test messages got snagged by SpamAssassin and placed in "Held Mail." Should have checked this first.
×