Farelf

Forum Admin
  • Content count

    7,012
  • Joined

  • Last visited

Everything posted by Farelf

  1. See fragile's solution (Shift-Alt-F) in http://forum.spamcop.net/forums/index.php?...amp;#entry82630
  2. No - that is "listwashing" which is NOT what responsible marketers do!!! They use confirmed opt-in to establish their mailing lists. Listwashing is what spammers try to do, See http://www.rickconner.net/spamweb/optin.html SpamCop deliberately shields the identity of reporters.
  3. You're welcome. E-mail marketing (without getting tagged as as spammer) is difficult and distribution lists need to be carefully managed to avoid that risk. Here is SC's general advice to those who have been reported by SC users - https://www.spamcop.net/reported.shtml There were a number of user reports concerning vs01.yaminyami.ru (46.4.63.154) in April. At that time they would have been passed on to abuse[at]hetzner.de in the event hetzner.de might have wanted to institute damage control before the server got itself into more trouble. Apart from the SCbl, that's the way SC works - as a sort of "early warning" system. There is no notification of SC spamtrap hits but in that instance SC reporters triggered detailed reports to the abuse desk anyway.
  4. Thanks username - it is a known problem which awaits fixing. Current contact information can be found at http://forum.spamcop.net/forums/topic/14783-what-is-spamcop/#entry91803
  5. Hello username. That message doesn't seem like it came from SpamCop blocklisting - info[at]yaminyami.com resolves to IP address 46.4.63.154 (vs01.yaminyami.ru) which is not blocked (see https://www.spamcop.net/w3m?action=checkblock&ip=46.4.63.154). Consulting http://multirbl.valli.org/dnsbl-lookup/46.4.63.154.html you can see that SORBS is the only serious RBL listing that server - yet again, the message format does not indicate that SORBS was interrogated to provide a reason to block. I think you (or someone) must talk to moscowpost.ru to find out why those messages are rejected. Maybe the cause is false positives from their own anti-spam application? (see P.S.) Good luck ! P.S. I see that your server has a POOR reputation in SenderBase - http://www.senderbase.org/lookup/host/?search_string=vs01.yaminyami.ru You have apparently sent (during April) a high volume of e-mail, including some to non-existent addresses and to several spamtraps. Also there have been many complaints that the messages were unsolicited and commercial (=spam) I cannot tell whether or not 46.4.63.154 was listed in the SCbl but it was certainly reported by SC users. I now think the rejection reason "due to content restrictions" is misconfigured, the real reasons are probably one or more of poor reputation (current)SCbl listing (no longer, spam has stopped) SORBS listing (current) receiving network private blocklist (?)
  6. I see "OrgAbuseEmail: disa.columbus.ns.mbx.arin-registrations[at]mail.mil" for 30.25.6.0 (ARIN). There's some sort of history there I seem to vaguely recall but I forget the detail
  7. Agree - and no, that "Received:" line doesn't look compliant - it should include IP address 216.82.255.55 for mail6.bemta7.messagelabs.com.
  8. Do not post any images on this site, thanks. See the item "Anti-spam" in Help for some rationale on this. As Lou says 92248[/snapback], copy and pasting the full spam source should resolve the actual spam-sending source, (There are many kinds of spam and in the most common types the sender e-mail addresses are false/spoofed.) You may like to refer to How do I get my email program to reveal the full, unmodified email?. The resulting plain text is suitable for copying and pasting into the (reporting) member submission form. Results can be discussed by reference to the Tracking URL which is available from the resulting parsing and reporting page. Whether or not you actually submit the report is up to you - it sounds like you do want to become a reporter. As Lou also says this is the start of the process that makes SC an effective tool in the fight against spammers - but as he also cautioned in his first post 92244[/snapback] you may not be seeing immediate results in terms of the instant elimination of "your" spam that you might have been anticipating.
  9. Just review and try to assimilate the information you have been given already. There's an awful lot of it, no need to get defensive - you have been trying to soak up in a month more than most of us managed to come to grips with over a period of years. You need to read and take onboard What is the SpamCop Blocking List (SCBL)?. A single reporter will never get any IP address listed - it takes several (nominally within the same 12/24 hour period) and/or spam from the subject address being detected by SC spamtraps (also within that short time frame). You are doing good in reporting even if it has not (yet) apparently resulted in listing. All it will take is one or a few other reporters to add their data ... It appears that the administrators of eonix,net have not been responsive (that is the other "string to the bow" for SC reporters). There can be many reasons for that - we reporters tend to assume it is because they are effectively complicit in the spam operation (because we're mostly paranoid). That assumption may or may not be justified. It is hard for others here to tell without Tracking URLs to help test the conjecture - for instance if the parsing and reporting page (pulled up by the Tracking URL) shows the IP address of the e-mail source is participating in a botnet as indicated by listing in the CBL those administrators might benefit from a user note (completed before releasing reports) pointing them to that fact. Ideally that might have immediate effect (for a single IP address out of many) but in large networks it is usually more complicated than that. But it is a start. But, in the examples you have shared, both the source of the e-mail and the hosting of the payload spam links (websites) are in the same network. That pattern is unlikely for botnets, it is more likely in a spam-friendly network and in that case we can't expect the administrators to be helpful in eliminating that spam. The only recourse is to keep reporting and trust that will contribute to a generally poor network reputation which might, in turn, have economic consequences that will eventually force the network owners to re-examine their business model.
  10. Thanks JoeF ... it would be hard indeed to disagree with your assessment. What can be done to bring them to account, I ask myself - unfortunately without any ready reply.
  11. I don't know what's going on, the devnul addresses usually substitute hash for arroba thus the previous abuse address was delwyn[at]tiburonhost.com but is now devnulled, probably because ownership of that netbloc has changed. You can always add craig[at]modvismedia.com for 104.140.95.174 and 104.140.95.253, or abuse[at]eonix.net (from http://whois.arin.net/rest/nets;q=104.140.95.174?showDetails=true&showARIN=false&ext=netref2), which you have found, as a user-defined reporting address to your reports for 104.140.95.174 and treereadmastkenp.info. You could also report your findings in the Routing / Report Address Issues subforum I will leave it to others to explain how to do any of that if you can't work it out because, frankly, I have run out of patience because ... Despite repeated requests, you continue to post spammer's live links - thus making this forum a spam host and yourself possibly a more effective spammer than the people you are reporting. The URIs in green in my edit of your last post were coming up as clickable links before I broke them. They may not have looked so in edit mode, but did you even review your post after you made it? I don't know what those links do but I do know they are supposedly the links the spammer wanted clicked or otherwise promulgated and which you continue to gleefully expose despite multiple exhortations to only reference spam content by pointing to the appropriate Tracking URLs.
  12. Haven't been there for ages but I think the way it works is - when you switch to mole status (via preferences) you stay a mole until you switch back. Such is entirely at your discretion, SC doesn't recommend anything (except to note that mole reporting is "mostly pointless"). If an abuse desk is known to SC as abusive, SC would not send reports. That is one of the several reasons why, in the reporting stage, some IP addresses/ranges might generate a message something like "No valid email addresses found, sorry!" (followed by a - partial - list of reasons). The main purpose of reporting is to build up statistics towards quickly listing an extensively abused IP address in the SCbl while the abuse is in progress. External reports to ISP/abuse desks are a courtesy - plus some ISPs are actually using those to control spam in their networks, the way it is intended. A double-barrelled approach but certainly there is no need for despondency if no ISP/abuse desk reports are sent, whatever the reason - "You can lead a horse to water, but you can't make him drink," eh? Feeding the SCbl is the "main game". When you opt for munged reports, SC will alert you if the ISP is known to reject those and will not send a report to them unless you take the option (for that individual report) to send an un-munged report. I think. It is fairly rare but you will know it, if you stumble into such a case. Don't sweat it - there is more than enough to learn - if you are resolved to "look under the hood" - without moiling in the dark depths of the more esoteric realms. The reporting process itself is generally quite easy.
  13. Spammers could, hypothetically, put an identifying code of their own devising in the headers or the body of the original spam. That would be a "tracking code". There is no evidence that they currently do this. If they did, their next problem would be to get a copy of the report from the ISP/abuse desk to which the report is sent so they could decode it to identify the reporter (for some unlikely purpose). SC would regard report sharing with spammers as a hostile act and discontinue sending reports to any such complicit ISP/abuse desk if there was any evidence/hint of it happening. There is no way spammers could see your munged e-mail address/details directly, even if they did get a copy of the ISP/abuse desk report. Some ISP/abuse desks do not accept munged reports. You would be given the opportunity to forgo munging in those specific instances. Even with an unmunged report, the spammer would have a problem seeing a copy. The Tracking URL is SC's link to the parsing and reporting page and is NOT to be confused with any hypothetical code which may or may not have been inserted in the original spam by the malefactors Silent reports are not sent to anybody, ISP/abuse desks get nothing. They are like 'devnul' reports, they only affect the SCbl statistics for the IP address "reported". EXCEPT the mole reporter's "silent" reports are discounted - they do not have the same "weight" as an ordinary report (even a devnulled one). They do not contribute much to tipping an abused IP address into the SCbl. But they may help keep a listed IP in the sin bin, when spam is continuing.
  14. Looking at the full source of the example you provided via Tracking URL, blocking the display of remote images should prevent the several images which could work as web bugs (though that is somewhat unlikely) quite effectively. There could be tracking codes in the text (or even the headers) but none are obvious and for any such to work the spammer would need to have access to the reports you send to servermania. SC staff take a dim view of abuse desks that feed the spammers (or are part of the spam enterprise) and will discontinue reporting to them if there is any evidence. There has been much discussion over the years of the "increased spam" some people observe when reporting, if you care to search that topic in these forums. Having seen those discussions as they took place, I keep coming back to "Why would the spammer bother?" The high-volume, scattergun operational model most use doesn't require either list maintenance or "pay-back"/revenge against reporters (and is reduced in effectiveness should the spammer resort to those). The Copernican principle would indicate you (or any of us) are unlikely to be a special target - mediocrity is our most likely lot in life. No, I think it is most likely all part of the "spam cycle" and they will just go away in time. You could take a holiday from reporting to see if it makes any difference - some, doing that in past times, have sworn it does. Others have sworn it doesn't. To a statistician such mixed results would indeed indicate the cycle is most probably independent of reporting.
  15. Hi db17, I'm afraid I don't know enough about your system/setup to suggest anything more in the way of filtering without adding a third-party solution (such as SpamAssassin) which you have already said is not suitable. There really ought to be a way to meet your needs with one of those but I'm afraid I don't know enough about that either. Perhaps some other helpful member could step in and advise ... I'm sure there are some who have their heads around the configuration you are using and practical solutions. Now, you haven't quite grasped the use of the Tracking URL - the URL is the only reference to post here in public, as now amended. When you post the text of the parse AS WELL, you are also posting the spamvertized links from the original spam and you are doing the spammer's job for him, except 1,000 times more effectively than he did in a single e-mail to you. And you are making this forum look spammy and unsafe to search engines and other monitors. Don't worry, lots of other people make the same mistake of not thinking through the consequences (or realize that the forum posting process converts plain text to live links) - just don't do it again, please. Use the URL of the parsing and report process page only, nothing else. Sure hope someone comes along with some ideas to keep that spam out of your inbox.
  16. If you view the full message source code per the external listing you provided - I removed the live link - that is the usual format to include in your spam submission. However, you could simply include the text you have posted instead (or a simplified version of that) - but a final line --Mark=_634250613171253082044-- may be required to close the content declarations in that example (not sure). There must be at least one blank line between the headers and the body. Getting back to the full source: It is permissible, but not required, to substitute decoded Base 64 in the spam body - see Material changes to spam But see the full context in the "material changes" link. HOWEVER I think that spam in its "full form" may exceed the 50k limit per individual spam (but it is OK to truncate the body). I had a brief look at the decoded content using http://www.toastedspam.com/decode64.cgi but had some problems due the utf-8 character encoding. SC's "main game" is finding the massage source - unless there are special reasons you may prefer to simply leave it at that and include just the body outline in your submission as you showed first up. That's what I would do, FWIW (without the line numbers or white space - except for a blank line between the headers and the message body).
  17. The payload is what the spammer wants you to see and do - in this case follow the link he is advertizing in the spam. It is perfectly common for one server/IP address to host any number of different websites within different domains, Those domains are not fake - the links wouldn't work if they were and there would be no point in advertizing them. You can look at the perlapostaeltronica.com domain from your example using https://www.robtex.com/ (select the first result) and just look at all the different sites on the one IP address under the "Shared" section, "Domains using the same mailservers as perlapostaeltronica.com" item (it takes a while to load). And that is only the first 100 of them, there will be more. You can filter on the IP addresses of "payload" websites from the spam body (it is arguably more efficient than filtering/blocking on the server addresses sending the spam - the source) but in your circumstance it would be more complicated, it would take an extra layer of processing through whatever filter or blocklist comparison you would need to be using, Far simpler to work with what is in the headers (the message source) since you already have direct access to that layer of information.
  18. (Excessive whitespace removed above). Sorry db17 - I have managed to confuse you quite comprehensively it seems. My fault - I just get too "wordy" the harder I try to explain, it's all "in there", just not clearly enough. Is it still confusing when you re-read it all? Doesn't matter, we can fairly-well start afresh now. I have been asking you to run the parser on some current sample spam and post the result. The header data you have provided is fine. The body text is "close enough" to parse. Here is what the Tracking URL looks like for that data: https://www.spamcop.net/sc?id=z6087547245z98b4e3c92fc33092e01fb750ffd6de02z This is a very straight-forward type of spam, a type successfully handled by the parser in great numbers every minute of every day. "My" parse works slightly differently to what yours might because I do not (and cannot) have your mailhosts set up. That makes it a little more vulnerable to "clever forgery" than yours would be. Don't worry about that, this is not a clever spam (few are). The details: the message source is 153.92.197.71that's the one you want to block to stop spam from that source reaching you there are no bogus "Received:" lines SC finds an abuse address postmaster[at]conware.de SC finds the "payload" spam advertized website is hosted on 193.86.21.118 SC has no suggested abuse address for that serverthat doesn't matter, still worth resolving in case the SURBL or others can use the data SC offers to report - it is up to the reporter whether or not reports are sent. Always, it is YOUR responsibility. You can cancel (as I did) or send. Whether you report or don't, you can use the information for other purposes, such as blocking. No reason you shouldn't do both on a case-by-case basis. The walk-around idea is a sound one and has been done before. The only problem is things change. Here is the previous main attempt http://forum.spamcop.net/forums/topic/2385-how-we-use-spamcop/ Many of those examples of differnt users with different systems and approaches involve the integrated SC mail system which no longer exists - though e-mail submission from other providers still works (alternative to using the paste-in webform). Neither does the "more user-friendly" version of the walk-around mentioned in that topic exist (we lost SCWiki in the last forum upgrade). But some of the information may be worth your review. I have the patience to try an update but I have neither the time nor the specific knowledge of your systems. Perhaps another user can help with Mac-OSX Mail or whatever it is. If there's a way to capture the raw text of entire message (including body) without opening the spam that would be good to know ... Too many words again - but please have a go at reading the parser detail in the Tracking URL and ask questions based on that to prevent us going around in circles. Don't worry if a message is included in the parse saying the information is too old to report (happens 48 hours after the message was first received by your provider. Parsing and reporting are different processes.
  19. Thanks for the explanation. Looks good - only thing is, you MUST HAVE one or more (blank) lines following the headers, followed in turn by some sort of message body. If there is a way to copy and paste the entire "message source" (AKA the "full, unmodified email") then the blank line(s) and body following the headers is all taken care of for you. The body is where the parser picks up the links to any spam-advertized content, You should find the details of how to capture that "full, unmodified email" within https://www.spamcop.net/fom-serve/cache/19.html. Looks easy enough, you've been doing that already to get to the "raw headers" I think? Just keep the full message that follows those too, for pasting in. We're in danger of "overthinking" this I reckon. The whole parser system is designed to work out (to the extent necessary) what is bogus and what is not, especially once you have your mailhosting configuration set up. Until you try a parse you are perhaps needlessly "second-guessing"? 193.86.21.118 appeared to be the host of a spam-advertized website payload from within the body of the spam - nothing to do with the source of the message which is what SC is good at detecting. The parser is designed to take care of both message source and "spamvertized" wesite resolution and usually lets you report to their respective administrators/abuse desks. The SCbl is for message sources (single IP addresses) only. There is no blacklist for those spamvertized websites. The SURBL has a blocklist served in part from SC submissions but is a separate entity. SC doesn't threaten anyone - not with blacklisting nor anything else. Used properly, SC reports should actually help those mail administrators inadvertently hosting spammers by giving them an early "heads up" before they fall into the clutches of other, sterner RBLs. The "X-Originating-IP:" header should (and mostly does) show the message (spam) source. But a little caution is needed (were it otherwise!), it can be "trivially", as they say, forged. Editing your own posts operates in an "edit window", as is the case with almost all forums that allow member edits. Not sure of the window "here" off-hand. It has been discussed in the past ad the answer should be "findable" by searching. But is is also very easy to get "lost" in multiple pages and lose hours of editing by dismissing the wrong one. I do that far too often myself. Direct to MX spam with extensively-forged headers is one kind of spam (in many varieties, a bit "old hat" these days in gerenal) but the parsing service has evolved to see through all of that malarkey. Of course the parser is not perfect but conjecture and second-guessing is fruitless. Just try some submissions (you can cancel them without sending reports if not confident) and discuss any specific cases here or with the SC staff directly by mail - be sure to use the Tracking URLs.
  20. Alas, I know nothing about the use of iptables but to keep stuff out of your inbox it is good to divert (with the subsequent opportunity to examine) the undesirable rather than to simply block. Seeing exactly what would otherwise be dropped adds a dimension to diagnosing what is happening. And allows reporting "in the greater good" because of course blocking by one account has no traction at all to affect the spam operations of the perpetrators whereas, as I have said, I think the various RBLs (and exercise of abuse addresses in conjunction with the SCbl at least) do have a detrimental effect on them over-all, though not necessarily an immediate one. Have you looked at SpamAssassin? Not being a Mac user I keep forgetting about it but I understand there is a long association with SpamCop, Past topics can easily be found by searching these forums.
  21. Way out of my league but those people seem to know their stuff - few alerts with (say) virustotal.com analysis (62 different scan engines, currently) on the (reconstituted) standida.com links and nothing at all with the consequent quttera.com scans on same for malware/suspicious behaviour/blacklists. SC's main game is the e-mail sources of the spam with not much focussed on the spam-advertized payloads. Normally we would be discussing a reporter's Tracking URLs for your examples (or current versions of them) and how the parsing and reporting service is performing in relation to those sources and spam payload sites. IMO SC is not really up to making much impression on operations such as these (might fray them a little around the edges) but, having members "here" with a broad range of knowledge and experience, hopefully some of them might have some thoughts. You're not a SC reporter are you? Or prepared to open an account (it's free)? We could do with a Tracking URL or two. Looks to me like SC would simply offer to report the standida.com and parantly.com "spamvertizing" to forona.com but the SURBL takes some of its feed from SC reported domains and THAT might cause some consternation to these miscreants. Not as sexy as taking down an entire zombie network but everything starts somewhere.
  22. Thanks for the questions dmspac - hopefully someone can address them for you. While you are feeling analytical, you may find https://www.robtex.com/ a useful resource. For instance enter 67.159.200.132, select first result "IP info about 67.159.200.132" and look at the information - progressively displayed, it takes time for it all to come up. It looks like Forona Technologies is fairly well known in computer security circles. SC mostly looks at the e-mail side of things and another resource you can use to explore that aspect is http://www.senderbase.org/ where the sending behaviour (and blacklisting in a number of RBLs) can also be gathered for other IP addresses in the same subnet/CIDR or optionally by domain/network owner. Incidentally, your Wikipedia link in the above is fine but the other external links (not counting the munged ones which I have 'de-linked' anyway) are "404" page not found.
  23. Sorry - probably can't be explained at an appropriate level without proper assessment of where you are in the learning curve (which most of us are still climbing which complicates things a bit as well) but rest assured it can be understood to a useful level by most with some little effort. For a digestible overview of the spam "industry" with layers of optional detail look at Rick Conner's http://www.rickconner.net/spamweb/ The "source address" address, as said before, is the address of the computer sending you the email. That is not the same as the server hosting the spam-advertized website(s) "payloads" with the ilgrandecomunicatore.com domain name. Utterly different beasts. 153.92.194.xxx (and 153.92.195.xxx) are part of a HUGE netbloc (153.0.0.0/8) directly allocated by InterNIC before the Regional Internet Registries were established (look those up if you want but it's just blah-blah). EXCEPT that makes tracking down who-ever is using/abusing them at any given time (using RIR-referred resources) a little more difficult - and if swapped around from spam to spam can degrade the value of any cached abuse.net addresses. Which is why spammers like using those IP addresses. All 16 million and a good many more possible addresses. Because people complain about the spamming abuse from them, one-by-one. SpamCop is evidently picking up abuse addresses via forwards-backwards verification of the accepted sending domain (from the accepted IP address and corresponding server name) and reaching into abuse.net (or is otherwise using the correct RIR, however established). Website servers are a little less easily shuffled around than are e-mail servers but, as discussed, sometimes they have to be moved anyway due to reporter pressure (or non-payment of accounts more likely ). You can see what is in the parse by going into your "Past Reports". Just click on that Report ID field that you have carefully blanked out in the images (needn't bother, only you and SC staff can use that) alongside one of (there can be several) the SOURCE IP address reports, as previously stipulated. That brings up the submitted spam, with a link to the parse at the very top. Follow that link and towards the top of the parse page there are a couple of lines looking like: "Here is your TRACKING URL - it may be saved for future reference: http://www.spamcop.net/sc?id=z641303267z045b750a0c3cf8aa3bfef3b3d92488bfz" That tracking URL can safely be posted here, in public, for discussion of the content and process. Ensures everyone sees the same thing at every level, preserves confidentiality and removes the risk of spreading the payload. It has a life of 90 days, That parse (a re-run) will show you the spam payload (website) IP address used for abuse address location NOW but it will ALSO show you the difference, if any, between the original report address ("Reports regarding this spam have already been sent:") and now. You can run a basic DNS check (the command-line nslookup procedure in an earlier post here - or there are any number of web-based services to do the same) of any such different domain (as sometimes indicated by the report address domain - or there are "other ways", no doubt). As you have correctly deduced, understanding the headers is a BIG THING, understanding the elements of the parse is an even bigger one and the effort needed is correspondingly greater. Reviewing the changes to reporting addresses puzzles many and is key to getting under the hood of the whole spam problem. You will understand none of us can individually spend such amounts of time with every 'enquiring mind" (would love to but time is precious and running serious risk of exposing limits of own knowledge already with concurrent risk of corrupting a whole new generation of Reporters). Which is a kindly-meant (and as self-deprecating as I get) way of saying for a précis of the "self help" resources, don't forget http://forum.spamcop.net/forums/topic/14783-what-is-spamcop/ But there will always be those niggling little queries - that is understood and perfectly acceptable. And others who are prepared to step in and offer guidance. The point I am trying to stress is - though reporting effort mightn't seem to do much good it has a hidden effect, both for the originating source and the spamvertized payloads - it inconveniences spammers and forces them to continually run hard just to stay in place. All of which I contend might be illustrated by your examples which a casual observer might conclude shows just the opposite. Steve
  24. SC, in that graphic of your Past Reports, was offering to send them to the network/DNS owners of the spamvertized websites at ilgrandecomunicatore.com which DNS records presently show to be hosted on: I'm fairly sure that the original parse (which you can pull up from the Report ID for the sources, would have shown that IP address in fact - it is the starting point (after any resolution of link obfuscation) to finding responsibe parties to which to report. It is subject to change - there's a FAQ on it somewhere - here: https://www.spamcop.net/fom-serve/cache/32.html. I'm currently showing "% Abuse contact for '193.86.21.0 - 193.86.21.255' is 'nic[at]t-mobile.cz' (RIPE Database query service).. SC often prefers an abuse.net abuse address or a cached one, for whatever reasons. Sometimes they (SC) will accept a reporter suggestion to use a RIPE (etc.) one instead. Reporting addresses can flop around from one day to the next (even - perhaps especially) within SC's reporting system), I think you just caught ilgrandecomunicatore.com in the process of "change". Maybe your reports helped force that? You don't really need to educate yourself on reading the parses - but I confess one probably needs to look at quite a few of them to understand any, in this "feature rich and dynamic" environment.
  25. Oh, there are "end user" solutions to using RBLs and other selective blocks. (Some) people here are always raving about Mailwasher. Just don't EVER use the "fake bounce" feature which used to be configured as a default selection for spam "handling" by that product, maybe still is. If you do, we shall collectively hunt you down and castigate you so comprehensively that any thought of future gene dilution on your part would remain forever an impossible dream. Or there are are other "consumer level" filters like http://wiki.spamihilator.com/doku.php and http://keir.net/k9.html - you would need to do some homework to see whether those can be configured to your installations and see whether their features suit you.