Re: List Spam Filtering
On Wed, May 15, 2013 at 12:18:18PM +1000, Da Rock wrote: I'm a big fan of _not_ having to subscribe to a list to get a quick hand with a one off problem (obviously not this one!)- otherwise too many lists get subscribed to, oodles of messages come in which you can't do anything about and so forth (so its not simply just a matter of subscribe, unsubscribe as noted). I concur with you, which is why point #2 in my message (which I've elided for brevity here) comes into play: if the list-owners set the subscribers only flag in Mailman, then messages from nonsubscribers will be held for their attention. I don't think it's unreasonable or particularly burdensome to request that they check that queue once a day or so, and decide how to dispose of those messages. I should also expand on that to mention that Mailman offers a number of choices on how that disposition is handled: list-owners can choose, for example, to add the address in question to a list of non-subscribers permitted to post, so that subsequent traffic from the same person won't be held up and require attention. I've found this quite useful for cases where interested individuals send traffic sporadically. I've also found it quite useful to note the email addresses of obvious spammers and block them at the MTA, because they'll often step through *all* the mailing lists sequentially and it becomes tedious to discard the same spam over and over. Blocking at the MTA alleviates this problem. Another way to put it is that while using this method involves a small initial effort, it has the significant advantage of not requiring any action on the part of legitimate message senders, and the effort required by list-owners diminishes over time. It also doesn't require any coding effort or external plumbing. Aside from all that, the last suggestion (4) should be possible using some simple filtering without the need to change the subscription parameters. It could be possible to even do it automatically saving further work on a list-owner. I urge caution on that: oh, it's a fine idea, but introducing automation into that process has its issues/risks. In practice, I've found (having run many mailing lists over many years) that the manual workload is so small that it's not worth automating. Since I've now opened my big mouth on this topic twice: if the list-owners are paying attention and wish assistance with this, I'm certainly willing to help out. ---rsk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: List Spam Filtering
1. Restricting mailing lists to subscribers only has been a best practice since the last century. It's a very good anti-spam tactic. 2. However, doing so -- for a list run via Mailman, like this one -- does not pose a significant impediment for non-subscribers. By default, Mailman will hold traffic from non-subscribers for list-owner approval. Provided the list-owners check that queue periodically and have reasonable spam-spotting abilities, this works beautifully. 3. Note that Mailman, as part of that same mechanism, allows list-owners to add non-subscribers to a list of those permitted to send traffic to the list without approval. This feature is probably more often used to allow traffic from alternative addresses for subscribers, e.g., someone is subscribed as f...@example.com but sends occasionally from f...@example.net. But it can just as easily be used for non-subscribers if the list-owners so choose. 4. List-owners may also find it useful to keep track of which spammers repeatedly attempt to abuse the list and block them at the MTA -- which has the desirable side effect of blocking them from ALL lists. I do this on a user/host/domain/network basis, and it's proven itself to be worth the effort. So: setting the subscribers-only flag on Mailman has major advantages, at the cost of additional work on the part of list-owners -- which can be mitigated in part across all lists by making changes to the MTA. ---rsk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Greybeards (Re: Netbooks BSD)
Unix, v6, on a PDP-11 (although I can't recall which model), circa 1977. Got away from it for a bit, then landed in the middle of the v6-v7 shift and the BSD takeover a couple of years later. Still recall being amazed by the Fujitsu Eagle (small form factor, large capacity). And I'm appalled that my phone has more horsepower than a dual-cpu VAX 11/780 with a floating-point accelerator. That just doesn't seem right. ---rsk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Why is sendmail is part of the system and not a package?
Having used sendmail since (quite nearly) the day it was released, and having also spent considerable time with postfix, exim, etc. in a variety of environments both small and quite large, I think I'm in a position to address this. Sendmail remains one of the best choices for an MTA. It's quite easy to configure for nearly all installations -- I would say that over the many I've done, most of those required only a few lines of changes to one of the m4 files to produce a fully-working configuration. It has an excellent feature set. It's maintained by some of the most experienced MTA people on this planet and while I don't agree with all of their design or implementation choices, I've learned to respect their judgment. It's readily configurable and customizable for some quite demanding and/or esoteric environments. It's documented exhaustively and considerable expertise abounds. It integrates well with just about everything, from webmail frontends to POP/IMAP servers to mailing list management software like Mailman. I see no reason at this time to change to another (default) MTA. Which is not to say that everyone should run the default MTA: some installations may require features which sendmail doesn't offer and can't be handled by milters. But in those cases -- where another MTA is required -- I expect the implementor to have the expertise to effect this change. ---Rsk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Looking for a Good FreeBSD and General Unix Backup System
On Tue, Jan 27, 2009 at 04:30:54PM -0600, Martin McCormick wrote: What we plan to do is backup a bunch of Unix systems to one FreeBSD box and then use a commercial package to back that box up to an enterprise-wide system we use. The archiver we need must be able to make 1 full backup of each system like tar and then incrementals until we are ready for another full backup. The best choice is dump, which was designed and built for exactly this purpose. (tar is fine for archives of static hierarchies, but it is not suitable for full-system backups.) Dump fully supports the concept of full/partial backups in a robust manner. (It has other useful features as well, notably its ability to deal with non-quiescent filesystems in a sensible way.) Excellent backup systems can be built with judicious use of dump -- you don't need to waste money on commercial products. [1] Depending on your specific requirements, it may be desirable to combine dump with other programs you already have (e.g., rysnc, gzip/bzip, scp, and so on). For example, I recently had occasion to build a system which backed up and replicated a multi-terabyte repository across a WAN. Using just the tools already on the system, and about 300 lines of shell (2/3 of which are comments), it wasn't that difficult to meet both requirements and do so in a way that minimized the bandwidth needed. This is really no big deal: it's just a matter of selecting the right tools and combining them -- which is the essence of the Unix philosophy. ---Rsk [1] Every commercial backup system I've evaluated for Unix -- over many, many years -- has produced inferior results. It pains me to watch people waste money on over-priced, under-performing and often-insecure commercial packages when they already have all the software they need...and just need to learn how to use it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Looking for a Good FreeBSD and General Unix Backup System
On Wed, Jan 28, 2009 at 05:11:22PM -0800, Doug Hardie wrote: Most certainly. Use the restore function. Interactive mode is easiest for a small number of files. Doug's correct. The interactive mode of restore, with its shell-like interface, is probably easiest if you're just looking for two files or one directory or similar. The non-interactive mode, which has a syntax similar to tar's, is probably easiest if you're going to restore many files/directories, or if you're going to restore an entire filesystem. Two notes to tuck away for future use: First, when you use interactive mode, you use shell-like commands (e.g., cd, ls) to navigate the directory hierarchy and pick out what you want to restore. You add each one to a list (that restore keeps track of for you) and then, when you've selected them all, you tell restore to extract them. This is point where restore will tell you that you haven't read any tapes yet, and ask you what tape to read. Tell it 1. There's a long explanation behind this that has to do with the days when 1600 BPI 9-track tapes were backup media, and dumps often spanned multiple tapes, and so on. Second, restore runs in user mode, so when it restores a file (or all the files in an entire filesystem) it creates them through the same mechanism any other user-mode program would. That means, from Unix's point of view, they're new files: new inode number, and all that. So if you're doing a major restore -- say, an entire filesystem -- then you probably want to follow that up with a level 0 dump if you plan to do partial dumps. Otherwise, those partial dumps aren't going to have what you probably want them to have. Arguably this is inconvenient but (a) it's a rare circumstance (b) it's not THAT inconvenient and (c) there's no good way around it without sacrificing a lot of the power of dump. Okay, three notes: it's often advisable to create a scratch directory and restore into that, just in case you fumble-finger something. Given that you're restoring, which means something has gone wrong, possibly a big something, you may be stressed and hurried, and thinking that this would be the worst possible time for something ELSE to go wrong. A scratch directory insulates you from most of that. (No, of course this is entirely based on other peoples' experiences, it would never relate to my own...why do you ask?) ---Rsk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
