Re: [vox-tech] Test/Upgrade
On 10/1/19 8:40 pm, Rod Roark wrote: Very cool to see the passion alive here. Apologies for not quoting it. :) I like Postfix and find these tips useful: https://www.linuxbabe.com/mail-server/block-email-spam-postfix On my own MTA I do use online blocklists and greylisting, but not spamassassin or antivirus. Not a big fan of content inspection. Rod Also this is an awesome Postfix anti-spam resource: http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt Took me a while to dig it up again; was last updated in 2015 but Postfix has changed little since then. Rod ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Test/Upgrade
Very cool to see the passion alive here. Apologies for not quoting it. :) I like Postfix and find these tips useful: https://www.linuxbabe.com/mail-server/block-email-spam-postfix On my own MTA I do use online blocklists and greylisting, but not spamassassin or antivirus. Not a big fan of content inspection. Rod ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Test/Upgrade
Quoting Bill Broadley ([email protected]): > Do you really think lugod's new mail server should be some weird > conglomoration of upstream source, > and out of tree patches? > > That's batshit insane in my book. Fortunately, I nowhere suggested that. Not intending to complain, and I gladly acknoledge that we have the best of intentions in this conversation and both have a sincere desire to help LUGOD, but this is the second time consecutively that I've pointed out that Boggis's ideas in his EximConfig tarball can and should be implemented with packaged software only and standard sysadmin work on conffiles, etc., for purposes of integration. > More details below. Apologies, good sir, but it's late, I've had a very long day and am tired, and therefore will merely attempt in all benevolence to cut to te chase. Boggis's tarball (and I'll speak from memory, here, so pardon a small amount of vagueness) is targeted primarily at Debian sysadmins and provides directions for which Debian binary packages to installto construct a highly effective MTA + antispam system built around the exim4-daemon-heavy package, the sa-exim package originally written by Marc Merlin, the spamassassin package, one or two packages related to SPF, and optional binary-packaged components that can be included to carry out greylisting, teergrubing (keeping records in MySQL), and probably a couple of other optional angles I'm not quite recalling. It also provides a set of Exim4 conffile snippets that unpack directly into the /etc/exim4 tree and integrate into the Debian-style many-fragments configuration structure that Debian package devs seem to like so much (viz. /etc/apache2/* and all its pieces), where the intent is to ensure smooth future upgrades of the distro packages (in this case, exim4-daemon-heavy and sa-exim) without anything breaking, segregating out local configuration as separate from what is replaced during upgrade. Likewise provided as working examples are controls exposed for tweaking all of this. (See tarball contents.) Part of what is distinctively good about the architecture Boggis describes with the cited packages as an example is that it does most of the heavy antispam lifting using MTA rulesets, a working Exim4 set of which are provided. This is critical to limiting RAM and CPU splurging, because MTA rules are typically implemented using C code (hence small and fast), so there's a huge amount of benefit in rejecting 95+% of arriving spam using MTA rules before handing off the SMTP bitstream to a ponderous, slow Perl daemon (spamd) to measure the spamicity of the remaining 5%. Boggis provides some truly clever MTA rules such as te 'callout' ones that test whether the delivering remote MTA is operating in an RFC-compliant manner _prior_ to accepting the mail with 250 Accept. The role of sa-exim is also key in Boggis's example, in that Marc Merlin's code enables (likewise) a consultation by the MTA to spamd to measure spamicity prior to the MTA deciding whether to say 250 Accept or 550 Die spammer die or 450 Please stick around while I greylist you. Among several advantages is that this decision-making _during_ the ongoing SMTP conversation prevents any possibility of creating backscatter spam. Now, the working files drop straight into Debian's _exim4_ setup, whereas many sysadmins would prefer to use Postfix, or Courier-MTA, or (God help you) qmail. Fine. This doesn't permit the drop-in functionality the way you can just unpack the stuff Boggis intends for the /etc/exim4 tree and have it Just Work{tm} effortlessly, _but_ all of Boggis's excellent ideas are right there to study and implement as you desire in whatever packaged MTA the sysadmin prefers. More can be easily learned by having a look at Boggis's documentation and his tarball. (I will mention once again that the tarball is _not_ a tarball of software, but rather of MTA rules and conffile snippets, etc.) Or, of course, if readers already think they have the whole thing covered and have nothing to learn from Boggis and Merlin's work, they can bag it and do something else. OK, then? I'm sorry, and intend no offence, but I'm going to assume (so I can hurry up and get to sleep) that the above covers what needs to be said, ergo I'm not going to read the rest of your post at this time. If there's something significant you think I really ought to read, I would welcome your telling me so. ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Test/Upgrade
Rick we seem to be violently agreeing on most technical details. I think a large part of the problem is you have too much experience and too much history. You can give a cursory glance at the 1700 line readme and have a good instinct for which pieces to ignore, which pieces to use, and which pieces need some polish. For someone who hasn't does this before that doc is a minefield. Sure there are good ideas, and bad ideas. Current ideas, obsolete ideas, and things missing. Do you really think lugod's new mail server should be some weird conglomoration of upstream source, and out of tree patches? That's batshit insane in my book. More details below. On 1/9/19 6:35 AM, Rick Moen wrote: > Quoting Bill Broadley ([email protected]): > >> I hear this line of thought, and am always puzzled by it. My recipe is: >> 1) run a current OS with a current spam assassin, like the newest ubuntu LTS >> or >>newest debian stable. >> 2) run postfix and whatever glue you like (mail filter, amavis, and amavis-ng >>are popular) >> 3) use greylisting > [...] > > I'm puzzled that you're puzzled. When you say "Architecting effective antispam for a modern mail server is an art form" it makes it sound rather difficult and mysterious. Not something as simple as install spam assassin, paste in a few lines of recipient/client/helo restrictions, and enable grey listing. Makes me think of someone actually spending many hours tuning, tinkering, doing, and redoing. Working late into the night by a small lamp, hungry, sleep deprived, and pulling ones hair out against the unstoppable spam onslaught. Not install mailserver, a few daemons, fire, and forget. > What I said was that a distro's out-of-the-box MTA configuration has > basically zero spam-rejection Your guide lists the anti-spam like SpamAssassin, SAS-Exim, and Exiscan as optional as well. >, which must be created by local > administrative effort. Indeed, an apt get, and 5 lines of conf file. One for amavis, one for grey listing, and few for smtpd/helo/client restrictions. I supect my total is more like 20 lines, but that's just preferences not just to get reliable mail delivery with minimal spam. > The meritorious configuration you describe is > not provided by any Linux distribution's out-of-the-box MTA > configuration, but must be created by local administrative effort. Indeed, but it's just a few lines of config and a few apt-get installs. > So, you agree with, and restate slightly differently, what I said -- yet > you claim to be puzzled by what I said? Just the difference between easy, install a few daemons, and something so hard/challenging that's an art form. > This is solving the wrong problem. > > If an SMTP host ceases to use alias redirectors (/etc/aliases and > ~/.forward) for cross-domain purposes, then the problem of 'forwarding a > malicious attachment' to a remote SMTP host basically goes away without > the collateral damage of neutering the file-attachment mechanism. Right, but requires not forwarding and doing things like publishing the email addresses of officers so they don't use the mail server... right? Not sending email through a server isn't a particularly good work around for an email server. Even without aliases and .forward, if a lugod member has an email on yahoo, gmail, or microsoft and they get a malicious attachment the likely result is making the blocking of delivery from lugod. There are replacements for /etc/aliases and .forwards that don't break SPF. I pipe to sendmail, or a short procmail can fix it. The more complicated solution is SRS, but is painful for various reasons. > (The > other type of mail reflector, MLM software such as Mailman and Sympa, > makes it easy to avoid being a malware reflector for reasons I won't > spend time covering here. It should suffice to note that LUG mailing > lists are not a vector for same.) I've heard several reports of large mail services blocking delivery from lugod, not sure what caused it though. Statistically speaking seems more likely to be mailing list related (a large volume of email) then direct mail to officers... but of course it's hard to tell. >> Heh, well using current software is much easier than engineering it from >> scratch. > > I'll note in passing that implementing some or all of the ideas in Boggis's > toolkit entails using current software, and not engineering any from > scratch. > > I would guess that you did not bother looking at Boggis's work before > commenting. I read the http://www.jcdigita.com/eximconfig/, looked hugely complicated, and somewhat fragile. Certainly with enough work I'm sure it works quite well. But pretty much turn key solutions work quite well without even needing to understanding much of what's on that page. Maintaining that solution looks like a part time job all in itself. Generally compiling sources code for any internet facing service seems borderline insane... unless you manage the
Re: [vox-tech] Test/Upgrade
Quoting Bill Broadley ([email protected]): > I hear this line of thought, and am always puzzled by it. My recipe is: > 1) run a current OS with a current spam assassin, like the newest ubuntu LTS > or >newest debian stable. > 2) run postfix and whatever glue you like (mail filter, amavis, and amavis-ng >are popular) > 3) use greylisting [...] I'm puzzled that you're puzzled. What I said was that a distro's out-of-the-box MTA configuration has basically zero spam-rejection, which must be created by local administrative effort. The meritorious configuration you describe is not provided by any Linux distribution's out-of-the-box MTA configuration, but must be created by local administrative effort. So, you agree with, and restate slightly differently, what I said -- yet you claim to be puzzled by what I said? > Your IP reputation (that causes non-delivery of email) can take a REAL > hit if you forward a malicious attachment. Is it really worth having > attachments if major mail services stop accepting email from you? This is solving the wrong problem. If an SMTP host ceases to use alias redirectors (/etc/aliases and ~/.forward) for cross-domain purposes, then the problem of 'forwarding a malicious attachment' to a remote SMTP host basically goes away without the collateral damage of neutering the file-attachment mechanism. (The other type of mail reflector, MLM software such as Mailman and Sympa, makes it easy to avoid being a malware reflector for reasons I won't spend time covering here. It should suffice to note that LUG mailing lists are not a vector for same.) > Heh, well using current software is much easier than engineering it from > scratch. I'll note in passing that implementing some or all of the ideas in Boggis's toolkit entails using current software, and not engineering any from scratch. I would guess that you did not bother looking at Boggis's work before commenting. > Not sure what you get by throwing everything away and using some > ancient guide. It's not an 'ancient guide', but I agree that you aren't sure. That's because, I gather, you didn't look. > Mail servers these days are nearly turnkey. And devoid of spam-rejection upon initial installation of just an MTA from a distro package. So we agree -- and yet you are arguing anyway. Well, I guess that's what I get for being on the Internet. > I'd start recommend with something updated in 2018 instead of 2011 though. The ideas Boggis collected in one place that were excellent in 2011 are sill excellent in 2019. FYI, Michael Paoli recently used Boggis's tarball and docs to create a new MTA configuration for Bay Area Linux User Group, and the only problem he found IIRC was the Perl SPF package reference being outdated. > Greylisting + current SA works wonders + sane postfix checks works > wonders. Keep in mind you can't just update the SA rules, you have to > update SA itself for the best protection. There are a number of things that need to be done with SA, including avoiding using all of the default weightings, for the simple reason that any halfway competent spamhaus tests spamicity against a default spamd configuration before sending. (Competent spammers are relatively rare, but there are enough of them to be a problem.) [problems with use of /etc/aliases or ~/.forward redirection for interdomain reflection:] > There are technical work around that are a pain in the ass. You're probably thinking of software to implement Sender Rewriting Scheme, as invented by Meng Wong in 2003, in the form of a wrapper Perl script intended to rewrite SMTP envelopes, semi-mimicking the way MLM software does that, using a variable envelope return path (VERP). I found this to be not only a pain in the ass but also that the results are downright peculiar, and that it's far more practical to simply cease using /etc/aliases and ~/.forward entries for cross-domain mail reflection. (As I said.) I'm also skittish about trusting pipes to Perl scripts in /etc/aliases (etc.) entries. There's a good (security) reason why the processing of those is now disabled by default in modern distros. > Sieve can do things like: > > if header :contains "To" "[email protected]" { > fileinto "admin.root"; > redirect :copy "[email protected]"; > } If I understand this bit of Postfix plumbing correctly, this is functionally exactly the same as having /etc/aliases entry root: [email protected] ...except I guess this would make Postfix write a new outbound SMTP envelope, making this a tiny improvement over the /etc/aliases equivalent -- but leaving in place the huge problem that lugod.org would mindlessly reflect any received spam (including as a subcatetory spam with attached MS-Windows malware) that passes MTA checking, and putting lugod.org at war with the receiving MTA's spam defences. That's exactly the problem LUGOD should want to avoid having. Hence my recommendation to dispose of the 'role' reflectors
Re: [vox-tech] Test/Upgrade
On 1/8/19 8:25 PM, Rick Moen wrote: > Architecting effective antispam for a modern mail server is an art form, > alas. You can very easily set up an MTA on essentially any Linux > distro, but it'll default to basically no spam-rejection at all, and > improving on that gets punted to the local administrator. Which sucks. I hear this line of thought, and am always puzzled by it. My recipe is: 1) run a current OS with a current spam assassin, like the newest ubuntu LTS or newest debian stable. 2) run postfix and whatever glue you like (mail filter, amavis, and amavis-ng are popular) 3) use greylisting That results in close to zero spam, at least for me. The only thing to change in the last decade is blocking the spam only domains like .click, .link, .party, .review, .science, .top, .webcam, .xyz, .stream, and .ga. Oh and I updated greylisting to deal with IPv6. Not many changes for a decade really. I did of course do an OS upgrade, every 5 years or so (last was 2016), haven't had to rebuild anything from scratch in a decade or so, the mailserver "just worked" each time. The only mail problem I recall was one of the bind upgrades that was incompatible with my configuration file for bind. Of course email didn't work without DNS. For LUGOD usage I do wonder if clamav is worth it, are attachments really worth the pain/memory/cost of running clamav? There's quite a few alternatives to sharing files via attachments these days. Your IP reputation (that causes non-delivery of email) can take a REAL hit if you forward a malicious attachment. Is it really worth having attachments if major mail services stop accepting email from you? > IMO, in architecting from scratch an effective spam defence, and finding > the right balance of false negatives vs. false positives, I've found > J.P. Boggis's 'EximConfig' tarball and accompanying documentation a good > starting place. Unavoidably, it has started to suffer from lack of > maintenance, e.g., the software recommended for SPF checking is no > longer packaged, so one must do more work than when it was last revised > around 2011. http://www.jcdigita.com/eximconfig/ Heh, well using current software is much easier than engineering it from scratch. Last time I did this it was apt-get install postfix-dovecot, 1 apt-get for amavis, and one postfix config line. Once that worked I moved all the tables into SQL. Typically the defaults "just work", just need to specify things like MyNetwork if you want hosts to be able to send outgoing email without a username/password. > I recommend studying Boggis's tarball & docs irrespective of whether one > uses the exact platform he targeted (Exim4 MTA on Debian), because his > ideas can be adapted. Not sure what you get by throwing everything away and using some ancient guide. Mail servers these days are nearly turnkey. "apt install postfix amavisd-new-postfix" will get you (or suggest to you) very recent versions of spamassassin, amavisd, clamav, postfix, SPF checking, etc. Doesn't take much glue to turn the above into a working mail server that will likely last with minimal tuning for another decade. I'd start recommend with something updated in 2018 instead of 2011 though. > For the separate problem of 'existing production SMTP host has a > terrible spam problem', that's a harder nut to crack without migrating > to a better-architected replacement, and you have my sympathies. Greylisting + current SA works wonders + sane postfix checks works wonders. Keep in mind you can't just update the SA rules, you have to update SA itself for the best protection. Sure if you want to keep tuning SA supports training on HAM and SPAM, but I've never bothered the spam is pretty rare as it is. > The other reason: Those aliases inherently fall afould of anti-forgery > techniques (SPF, DMARC), and so, depending on the mail's sender domain, > are at grave risk of getting either rejected upon redelivery or > spamboxed. This cannot realistically be fixed. My current view is > that /etc/alias or ~/.forward redirection is now suitable and reliable > only for intradomain purposes. There are technical work around that are a pain in the ass. But generally I recommend avoiding .forward, aliases, and similar for mailing lists. Seems fine for [email protected] to [email protected]. I keep my forwards, users, domains, and maildirs in mysql. Supporting a new mail domain is just an sql insert statement. Mailman + postfix can be configured to skip the /etc/aliases hack, that way you don't end up with a computer program (mailman), and a human fighting over the state of a single text file that's easy to corrupt with a single wrong character. Sympa seems more functional, more enterprisey, but generally overkill for what I know of the Lugod use cases. > The other type of redirection (other than the /etc/alias and ~/.forward > one) is of course mailing list managers (MLMs) like Mailman and Sympa. > These have the advantages that (1) th
Re: [vox-tech] Test/Upgrade
Quoting Timothy D Thatcher ([email protected]): > What happened was that I discovered earlier today that ClamAV had > apparently been misbehaving and had tanked mail/listserv service > entirely, and for a few days, it turned out. I also actually ran an > apt update/upgrade and rebooted the server myself several hours ago, > and indeed it brought the mail server roaring back to life... which is > probably why you've been seeing all those messages suddenly, as it > tries to process through the backlog. Sorry about the blast of > mailer-daemon notices. How/where are you receiving them? > > I'm still getting chunks of mail blasting in, myself, both daemon > notices and junk. I installed clamAV (and spamassassin, too) a while > ago when I was trying to clean up the mail server a bit. I question would the utility and effectiveness of _ClamAV_ in the use-case of the LUGOD MLM/MTA server. I think that's solving the wrong problem. (I realise that you almost certainly inherited the problem.) In the context of a LUG's officers, malware mail isn't a problem because of the malware. It's just funny-looking spam. The problem really is the spam. So, use good antispam. Which brings me to: Architecting effective antispam for a modern mail server is an art form, alas. You can very easily set up an MTA on essentially any Linux distro, but it'll default to basically no spam-rejection at all, and improving on that gets punted to the local administrator. Which sucks. IMO, in architecting from scratch an effective spam defence, and finding the right balance of false negatives vs. false positives, I've found J.P. Boggis's 'EximConfig' tarball and accompanying documentation a good starting place. Unavoidably, it has started to suffer from lack of maintenance, e.g., the software recommended for SPF checking is no longer packaged, so one must do more work than when it was last revised around 2011. http://www.jcdigita.com/eximconfig/ I recommend studying Boggis's tarball & docs irrespective of whether one uses the exact platform he targeted (Exim4 MTA on Debian), because his ideas can be adapted. For the separate problem of 'existing production SMTP host has a terrible spam problem', that's a harder nut to crack without migrating to a better-architected replacement, and you have my sympathies. > We have a pretty severe incoming spam problem, and particularly the > way much of it is getting processed/procmailed out to me and other > officers using gmail and similar services has actually been kind of a > serious problem--and one that is going to need revisiting eventually. Here, you're talking about /etc/aliases-based redirection, right? In other words, root@, sys@, typescript@, @devnull@, if@, demo@, pr@, and webmaster@ ? If so -- frankly -- here in 209, y'all need to give those up. You've noticed, obviously, part of the reason: Those aliases get clobbered as collateral damage in the spam war, and have been increasingly for about a decade and a half. The temptation is to think that you can keep making those feasible if only you make the MTA's spam-rejection really, really exceptional, except that it'll never be quite good enough. The more spam you forward via aliases (either /etc/alias entries or ~/.forward files), the more the receiving MTA perceives your relaying host as a spamhaus, and punishes it, especially receiving domians like gmail.com that do dynamic scoring of spamicity. The other reason: Those aliases inherently fall afould of anti-forgery techniques (SPF, DMARC), and so, depending on the mail's sender domain, are at grave risk of getting either rejected upon redelivery or spamboxed. This cannot realistically be fixed. My current view is that /etc/alias or ~/.forward redirection is now suitable and reliable only for intradomain purposes. The other type of redirection (other than the /etc/alias and ~/.forward one) is of course mailing list managers (MLMs) like Mailman and Sympa. These have the advantages that (1) they rewrite the SMTP envelope, hence can be made to comply with anti-forgery techniques, and (2) they have exactly the substantial built-in intelligent handling and filtering that is missing from the other redirection types. Someone might eventually suggest converting root@, sys@, typescript@, etc. each to its own Mailman mailing list. Don't. The manual administration and hassle required will drive you batty. > I'm up for suggestions on the next move. 1. Cease using /etc/alias entries for cross-domain redirection. (Yes, this is a painful step and an end to a cherished LUGOD tradition.) Instead, list on http://www.lugod.org/contact/ the office-holders' current direct, real, e-mail addresses. 2. Next SMTP host rebuild, spend about a week working on a modern antispam architecture for it, possibly with reference to Boggis's work. Expect it to take real sysadmin work, not just package installation. Sorry to be the bearer of bad news. __
Re: [vox-tech] Test/Upgrade
Tim, I see what you mean. The server is into swap space but is responsive and working, so nothing seems urgent. Probably what you want to do is research current best practices for spam control. Cheers, Rod On 8/1/19 5:49 pm, Timothy D Thatcher wrote: Rod, Oh lord. It appears that the beginning-of-month "reminder that you're on a listserv" emails all fell within that time period. Those emails timed out, which generated an email to tell us that it's timed out, which didn't get sent because *all* mail was timing out, all due to clamav apparently silently failing. Once clamav was brought back, it's started grinding through that queue... yikes. It's currently chewing up a huge block of memory. I am now entirely rethinking clamav's existence on the server. :/ Tim On Mon, Jan 7, 2019 at 10:14 PM Rod Roark wrote: Hi Tim, I just sent you a sample. I'm not a procmail guru... perhaps someone else here has ideas. Regards, Rod On 8/1/19 4:55 pm, Timothy D Thatcher wrote: Hi Rod, Primarily me now, I think. What happened was that I discovered earlier today that ClamAV had apparently been misbehaving and had tanked mail/listserv service entirely, and for a few days, it turned out. I also actually ran an apt update/upgrade and rebooted the server myself several hours ago, and indeed it brought the mail server roaring back to life... which is probably why you've been seeing all those messages suddenly, as it tries to process through the backlog. Sorry about the blast of mailer-daemon notices. How/where are you receiving them? I'm still getting chunks of mail blasting in, myself, both daemon notices and junk. I installed clamAV (and spamassassin, too) a while ago when I was trying to clean up the mail server a bit. We have a pretty severe incoming spam problem, and particularly the way much of it is getting processed/procmailed out to me and other officers using gmail and similar services has actually been kind of a serious problem--and one that is going to need revisiting eventually. I'm up for suggestions on the next move. Tim On Mon, Jan 7, 2019 at 9:29 PM Rod Roark wrote: Checking if this still works. To LUGOD admin(s): I started getting a ton of "Undelivered Mail Returned to Sender" emails from [email protected]. It looked like ClamAV being outdated might have been an issue so I did an upgrade and rebooted. Not sure if that mattered though. Who's the LUGOD admin these days? Rod ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Test/Upgrade
Rod, Oh lord. It appears that the beginning-of-month "reminder that you're on a listserv" emails all fell within that time period. Those emails timed out, which generated an email to tell us that it's timed out, which didn't get sent because *all* mail was timing out, all due to clamav apparently silently failing. Once clamav was brought back, it's started grinding through that queue... yikes. It's currently chewing up a huge block of memory. I am now entirely rethinking clamav's existence on the server. :/ Tim On Mon, Jan 7, 2019 at 10:14 PM Rod Roark wrote: > > Hi Tim, I just sent you a sample. > > I'm not a procmail guru... perhaps someone else here has ideas. > > Regards, > Rod > > On 8/1/19 4:55 pm, Timothy D Thatcher wrote: > > Hi Rod, > > > > Primarily me now, I think. > > > > What happened was that I discovered earlier today that ClamAV had > > apparently been misbehaving and had tanked mail/listserv service > > entirely, and for a few days, it turned out. I also actually ran an > > apt update/upgrade and rebooted the server myself several hours ago, > > and indeed it brought the mail server roaring back to life... which is > > probably why you've been seeing all those messages suddenly, as it > > tries to process through the backlog. Sorry about the blast of > > mailer-daemon notices. How/where are you receiving them? > > > > I'm still getting chunks of mail blasting in, myself, both daemon > > notices and junk. I installed clamAV (and spamassassin, too) a while > > ago when I was trying to clean up the mail server a bit. We have a > > pretty severe incoming spam problem, and particularly the way much of > > it is getting processed/procmailed out to me and other officers using > > gmail and similar services has actually been kind of a serious > > problem--and one that is going to need revisiting eventually. I'm up > > for suggestions on the next move. > > > > > > Tim > > > > > > On Mon, Jan 7, 2019 at 9:29 PM Rod Roark wrote: > >> Checking if this still works. > >> > >> To LUGOD admin(s): I started getting a ton of "Undelivered Mail Returned > >> to Sender" emails from [email protected]. It looked like ClamAV > >> being outdated might have been an issue so I did an upgrade and > >> rebooted. Not sure if that mattered though. > >> > >> Who's the LUGOD admin these days? > >> > >> Rod > >> > >> ___ > >> vox-tech mailing list > >> [email protected] > >> http://lists.lugod.org/mailman/listinfo/vox-tech > > ___ > > vox-tech mailing list > > [email protected] > > http://lists.lugod.org/mailman/listinfo/vox-tech > > > ___ > vox-tech mailing list > [email protected] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Test/Upgrade
Hi Tim, I just sent you a sample. I'm not a procmail guru... perhaps someone else here has ideas. Regards, Rod On 8/1/19 4:55 pm, Timothy D Thatcher wrote: Hi Rod, Primarily me now, I think. What happened was that I discovered earlier today that ClamAV had apparently been misbehaving and had tanked mail/listserv service entirely, and for a few days, it turned out. I also actually ran an apt update/upgrade and rebooted the server myself several hours ago, and indeed it brought the mail server roaring back to life... which is probably why you've been seeing all those messages suddenly, as it tries to process through the backlog. Sorry about the blast of mailer-daemon notices. How/where are you receiving them? I'm still getting chunks of mail blasting in, myself, both daemon notices and junk. I installed clamAV (and spamassassin, too) a while ago when I was trying to clean up the mail server a bit. We have a pretty severe incoming spam problem, and particularly the way much of it is getting processed/procmailed out to me and other officers using gmail and similar services has actually been kind of a serious problem--and one that is going to need revisiting eventually. I'm up for suggestions on the next move. Tim On Mon, Jan 7, 2019 at 9:29 PM Rod Roark wrote: Checking if this still works. To LUGOD admin(s): I started getting a ton of "Undelivered Mail Returned to Sender" emails from [email protected]. It looked like ClamAV being outdated might have been an issue so I did an upgrade and rebooted. Not sure if that mattered though. Who's the LUGOD admin these days? Rod ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Test/Upgrade
Hi Rod, Primarily me now, I think. What happened was that I discovered earlier today that ClamAV had apparently been misbehaving and had tanked mail/listserv service entirely, and for a few days, it turned out. I also actually ran an apt update/upgrade and rebooted the server myself several hours ago, and indeed it brought the mail server roaring back to life... which is probably why you've been seeing all those messages suddenly, as it tries to process through the backlog. Sorry about the blast of mailer-daemon notices. How/where are you receiving them? I'm still getting chunks of mail blasting in, myself, both daemon notices and junk. I installed clamAV (and spamassassin, too) a while ago when I was trying to clean up the mail server a bit. We have a pretty severe incoming spam problem, and particularly the way much of it is getting processed/procmailed out to me and other officers using gmail and similar services has actually been kind of a serious problem--and one that is going to need revisiting eventually. I'm up for suggestions on the next move. Tim On Mon, Jan 7, 2019 at 9:29 PM Rod Roark wrote: > > Checking if this still works. > > To LUGOD admin(s): I started getting a ton of "Undelivered Mail Returned > to Sender" emails from [email protected]. It looked like ClamAV > being outdated might have been an issue so I did an upgrade and > rebooted. Not sure if that mattered though. > > Who's the LUGOD admin these days? > > Rod > > ___ > vox-tech mailing list > [email protected] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
