Re: [Mimedefang] Fwd: Re: clamav vs clamd vs clamscan
On Mon, Oct 13, 2014 at 4:46 PM, Cliff Hayes wrote: > Two problems: > > a) the shell for clamav is set to /sbin/nologin so I can't su to it ... > should I change the shell? You can do: "su -s /bin/bash clamav'. > b) the email files clamd is trying to look at never stay on the server for > more than a second or two. At least see if you can access anything that needs the defang group. If it doesn't work manually, then there group is set up wrong. If it does, something must be wrong with the clamd startup that it isn't picking up the group membership. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Fwd: Re: clamav vs clamd vs clamscan
On Mon, Oct 13, 2014 at 4:30 PM, Cliff Hayes wrote: > restarted clamd; same error > > permissions for each directory up to and including /var/spool/MIMEDefang: > > drwxr-xr-x. 22 root root4096 Oct 7 14:55 var > drwxr-xr-x. 14 root root 4096 Oct 7 12:49 spool > drwxr-x--- 3 defang defang 4096 Oct 13 16:23 MIMEDefang > > I tried 755 on MIMEDefang and still got same error: > > drwxr-xr-x 3 defang defang 4096 Oct 13 16:23 MIMEDefang > > selinux is not running at this time > and I have the following option set: > > MD_ALLOW_GROUP_ACCESS=yes If you su to the clamav user, can you read the file in question? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Fwd: Re: clamav vs clamd vs clamscan
On Mon, Oct 13, 2014 at 4:01 PM, Cliff Hayes wrote: > Per other comments I removed all traces of previous clam installs and > started over with binaries. > Got clamd running as root and mimedefang running as defang - no problem. > But I'd like to run clamd as clamav so I did your idea and added defang to > clamav as such: usermod -G defang clamav > So now clamd is a member of two groups: clamav and defang but I still get > the following error: > > Oct 13 15:53:47 sendmail mimedefang.pl[27449]: s9DKrlSJ027472: Clamd > returned error: lstat() failed: Permission denied. > > Oct 13 15:53:47 sendmail mimedefang.pl[27449]: s9DKrlSJ027472: Problem > running virus scanner: code=999, category=swerr, action=tempfail > > Mon Oct 13 15:53:47 2014 -> WARNING: lstat() failed on: > /var/spool/MIMEDefang/mdefang-s9DKrlSJ027472/Work Did you restart clamd after the change? Also , check that the directories above /var/spool/MIMEDefang/mdefang-s9DKrlSJ027472/Work have rx permissions for group or other and the new files mimedefang is creating have group access. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Fwd: Re: clamav vs clamd vs clamscan
On Sun, Oct 12, 2014 at 4:54 PM, Richard Laager wrote: > On Sun, 2014-10-12 at 14:18 -0500, Cliff Hayes wrote: >> I tried your idea. >> I updated the following in clamd.conf: >> LocalSocket /var/run/clamav/clamd.socket >> PidFile /var/run/clamav/clamd.pid >> User clamav >> >> Now I get this error when starting clamd: >> ERROR: Can't open/parse the config file /usr/local/etc/clamd.conf >> I am starting as root as instructed in clamd.conf >> I have gotten that error before ... it usually means there is a user >> issue. When I go back to running as root it knows to look in /etc/ for >> clamd.conf > > I have no idea why your clamd is looking in /usr/local/etc instead > of /etc. There are probably 2 or more different version of clamd on this system, built with different default options. If packages have been installed from different 3rd party repositories or installed from source plus a packaged install, that is a likely scenario. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] clamav vs clamd vs clamscan
On Wed, Oct 8, 2014 at 2:05 PM, Cliff Hayes wrote: > I will have to go with clamd because clamav is taking 12 seconds to scan an > email with five words in it. > > I tried disabling all repositories except epel like this... > yum --disablerepo=atrpms-bleeding --disablerepo=atrpms > --disablerepo=atrpms-testing --disablerepo=elrepo --disablerepo=epel-testing > --disablerepo=rpmforge --disablerepo=sl6x --disablerepo=sl install clamd > ... but then I got a long list of dependencies, then a bunch of errors and > requires, then ended with this... > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > ... so I guess I should go back to binaries? Mixing 3rd party repos generally leads to conflicts. On a Centos system with EPEL as the only extra repo it 'just works'. Either you already have some conflicting package from a different repo or you needed something from the base SL.Also, if you get mimedefang and clamd from different repos you may end up with a mismatch in user/group settings that will cause permission problems on the socket they use to communicate. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] clamav vs clamd vs clamscan
On Wed, Oct 8, 2014 at 11:52 AM, Cliff Hayes wrote: > I am installing a new mail server on Scientific Linux 6.5. > What is the recommended way to install clam for mimedefang? > I have used binaries in the past but would prefer to use yum package unless > binaries are better for some reason. > I have listed the available packages below ... clamd won't install via yum > ... i get a message that it was obsoleted by clamav. > I see examples on the internet that mimedefang can fall back to clamscan if > clamd fails but I don't know which packages to load to enable that. > Now that clamd is no longer available, what is the recommended course of > action? > > clamav-db.x86_64 : Virus database for clamav > > clamd.x86_64 : The Clam AntiVirus Daemon > > clamav.x86_64 : Anti-virus software Is that from SL's own repository? EPEL has clamd and it pulls clamav as a dependency. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] ADMINISTRIVIA: Yahoo users may not post to this mailing list
On Wed, Apr 23, 2014 at 10:26 AM, wrote: > >> So, is it time for mailing lists to rewrite the From: header? I've >> always preferred ones that supply a Reply-To: back to the list so >> people don't accidentally answer off-list anyway, but I know there are >> arguments on the other side. > > That seems to be the consensus on the Listserv(TM) mailing lists. They > are doing it selectively after doing a DNS Query and detecting the broken > setting. See > http://peach.ease.lsoft.com/scripts/wa-peach.exe?A2=ind1404&L=LSTOWN-L&F=&S=&P=61953 That's ummm, interesting, that you can't see their example format without a login. But it looks like they want to rewrite the Reply-To: as the original sender which seems very wrong, at least for technical lists where most posters would never want to request a private reply.And doing anything 'selectively' also seems wrong if you ever expect users to catch on to how a system works. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] DMARC pessimism (was Re: ADMINISTRIVIA: Yahoo users may not post to this mailing list)
On Wed, Apr 23, 2014 at 10:25 AM, Joseph Brennan wrote: > > Les Mikesell wrote: > >> A standard for user interfaces??? What planet do you expect that to >> happen on? > > > > It makes a lot more sense than DMARC-- because it addresses the problem > Yahoo and AOL say they want to solve-- mail to their users that is faked. > > Systems with a web mail focus have total control their user interface and > could just do it. Oh, I'm not arguing with the concept. I just have no faith in any two administrators or software developers ever agreeing on anything. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] DMARC pessimism (was Re: ADMINISTRIVIA: Yahoo users may not post to this mailing list)
On Wed, Apr 23, 2014 at 9:50 AM, David F. Skoll wrote: >> These moves, by the way, will have the effect of rendering DMARC completely > useless. Mailing-list owners will change the From: header to > look something like: > > From: "pos...@yahoo.com" > > Users will see "pos...@yahoo.com" in their MUA. They will see a > successful DMARC pass. The concern I raised at > http://www.dmarc.org/pipermail/dmarc-discuss/2012-February/000189.html > will continue to go unaddressed. A standard for user interfaces??? What planet do you expect that to happen on? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] ADMINISTRIVIA: Yahoo users may not post to this mailing list
On Wed, Apr 23, 2014 at 9:32 AM, Joseph Brennan wrote: > > The madness has spread to AOL effective yesterday 4/22. > >> host -t txt _dmarc.aol.com > > _dmarc.aol.com descriptive text "v=DMARC1\; p=reject\; pct=100\; > rua=mailto:d...@rua.agari.com\; ruf=mailto:d...@ruf.agari.com\;"; > So, is it time for mailing lists to rewrite the From: header? I've always preferred ones that supply a Reply-To: back to the list so people don't accidentally answer off-list anyway, but I know there are arguments on the other side. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Tue, May 7, 2013 at 4:36 PM, wrote: > >> This sort-of depends on the level of confidence you have in your >> scanning tools. I don't think anyone wants to receive virii, although >> an end user should have equal quality antivirus protection anyway. In >> any case if you reject with an appropriate reason you have fulfilled a >> mailer's obligations. > > Your theory doesn't permit you to have it both ways. Since you seem to agree > that rejecting virus content at the systemwide level is appropriate, I find > your notion of letting the end user decide everything to be nonsense. Rejecting anything for any reason is appropriate as long as the sender gets a reasonable non-delivery notification. But, you aren't providing a particularly useful service if you reject reasonable content routinely. As I mentioned, google gets it wrong regularly, and you didn't answer my question about why you think you can do it better. And I only know that google gets it wrong because they toss it in a spam folder that I can check myself. Most of what they misclassify would have been bulk-mailed stuff, but it is stuff that I've requested or mail list messages where I am subscribed. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Mon, May 6, 2013 at 7:12 PM, wrote: > >> So, you can pass your knowledge on to the recipient, leaving the >> disposition up to them. For example, I think google is probably as >> good as anyone at that sort of bulk-discovery, and yet I regularly >> find things they've tossed in the spam folder that are not spam. Why >> do you think you have less false positives then they do? > > 1) Not always. For example, with a dictionary attack, for most of the > attempts, there will be no valid user to pass on such information, and it's > pretty obvious that when such an attack does hit a valid mailbox, that > recipient should NOT get malicious message at all. I'm not sure "pretty obvious" is the same as never having false positives, but.. > 2) Because I'm not a target of spammers like Google is. > > Passing on a message to the user means accepting responsibility for it, which > in turn implies to the spammer that the mailbox was valid (and it usually is > or is a spamtrap). Such messages cannot be rejected during the SMTP > transaction (because one is accepting them to let the user determine its maliciousness). Delivering a message or rejecting with as appropriate a message for the sender as possible is a mailer's "responsibility". Passing various levels of judgement on the content is an optional feature. > Under your theory, an MTA should pass on messages containing e-mail virii > too, so the user can determine it (or get infected for the not-so-savvy > users). This latter point I clearly disagree with. This sort-of depends on the level of confidence you have in your scanning tools. I don't think anyone wants to receive virii, although an end user should have equal quality antivirus protection anyway. In any case if you reject with an appropriate reason you have fulfilled a mailer's obligations. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Mon, May 6, 2013 at 2:37 PM, wrote: >>> >> Do you agree that end user recipients should have the final decision >> about message disposition? And that they probably do want forwarded >> messages whether or not the forwarder handles them in a way you deem >> appropriate? > > No, because some types of scanning and responses can only be administered > site-wide by the administrator (i.e. the software configuration) which cannot > be changed on a per-user basis. Take for an example a message cross- or > multi-posted to many users (e.g. perhaps from a mailbox dictionary attack): > Individual users will be unaware of its bulk nature and perhaps ONLY the bulk > nature will classify it as spam. So, you can pass your knowledge on to the recipient, leaving the disposition up to them. For example, I think google is probably as good as anyone at that sort of bulk-discovery, and yet I regularly find things they've tossed in the spam folder that are not spam. Why do you think you have less false positives then they do? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Mon, May 6, 2013 at 1:29 PM, wrote: > --- On Mon, 5/6/13, Les Mikesell wrote: >> How so, when they add setup and processing effort and don't add value? >> It is the content that determines whether I think something is spam >> or want to read it, not the mechanics of how the message was sent or >> the forwarding path (which I may have set up myself). > > So you claim that message forgery isn't a problem? Get a clue. No, but I claim that wasting time and effort on things that don't solve the problem are a waste of time and effort. So you claim the problem is solved? Does an end-user recipient have a standard way of seeing who thinks any particular message was forged and why? > I agree that spaminess and source authentication are separate issues, but > most recipients don't want forged messages either, spam or not. Do you agree that end user recipients should have the final decision about message disposition? And that they probably do want forwarded messages whether or not the forwarder handles them in a way you deem appropriate? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Mon, May 6, 2013 at 2:23 AM, Benoit Panizzon wrote: >> > Backscatter for the most part is not a problem because it has a simple >> > solution: Message source authentication, with varying implementations >> > and degrees of success - SPF, DKIM, MTX, PGP-signatures, etc. >> >> Various degrees of failure would be a better description > > Ack! > > It good that there are attempts to solve the problem. How so, when they add setup and processing effort and don't add value? It is the content that determines whether I think something is spam or want to read it, not the mechanics of how the message was sent or the forwarding path (which I may have set up myself). -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Fri, May 3, 2013 at 12:56 PM, wrote: > >> The problem case is where a spammer discovers that sending to an >> address will generate a bounce and sends with forged 'from' addresses >> that are intended as the eventual targets. So there is potential for >> damage, but it doesn't necessarily override the responsibility to >> deliver or report failures. > > The above is not only a backscatter problem but the fundamental flaw in > challenge-response systems (because to be useful, the challenge message must > quote some part of the message under challenge -- even if it's just the > subject line). > > Backscatter for the most part is not a problem because it has a simple > solution: Message source authentication, with varying implementations and > degrees of success - SPF, DKIM, MTX, PGP-signatures, etc. Various degrees of failure would be a better description -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Fri, May 3, 2013 at 11:24 AM, Tilman Schmidt wrote: > > Backscatter OTOH is a nuisance, which should be minimized of course, but > cannot be completely avoided. Blacklisting because of backscatter would be a > Bad Idea (TM) which I thankfully never encountered so far, but if someone did > that it would certainly be their own fault if they blocked legitimate mail as > a result. In my experience, misguided measures like that tend to get lifted > very quickly if senders and (intended) recipients of blocked mails are > informed in no unclear words who's responsible for the communication failure. The problem case is where a spammer discovers that sending to an address will generate a bounce and sends with forged 'from' addresses that are intended as the eventual targets. So there is potential for damage, but it doesn't necessarily override the responsibility to deliver or report failures. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Fri, May 3, 2013 at 1:18 AM, Benoit Panizzon wrote: >> Sooo,,, How does the real sender of the email ever find out that he >> sent to a broken address? > > Well, what's worse? > > - Backscatter? (and getting your server in blacklists because of that). > - Sender not knowing his email got not forwarded (but the one forwarding his > address can check upon that). Depends on whether you think email should actually be a useful form of communication or not. If I can't tell an address that has been given to me is never going to be delivered, it is not very useful. > I do consider backscatter the more serious problem. If you don't care if things are delivered or not, why not save the trouble and reject everything? Maybe there's some way to do the forwarding in real-time and pass back the result. Might be difficult in the general case of forwarding to multiple recipients or where the destination expands to a list with mixed results, but for one->one it seems theoretically possible. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to change envelope sender?
On Thu, May 2, 2013 at 8:57 AM, Benoit Panizzon wrote: > >> > So let's change the sender to the address of the address of the local >> > recipient who wants to have his emails forwarded somewhere else. So he >> > get's the blame/bounce if his forward does not work. >> >> I would expect that to loop, since the local recipient forwards to the >> address that is not accepting mail. How do you avoid that? > > I'm aware of that :-) > I'll probably add some kind of loop detection header or use some other logic > to detect loops or bounces which would loop (eg match empty sender). But one > problem at the time please :-) Sooo,,, How does the real sender of the email ever find out that he sent to a broken address? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spammers - was Re: md_check_against_smtp_server and md_graphdefang_log
On Wed, Mar 27, 2013 at 8:49 AM, David F. Skoll wrote: > > Welcome to the IT industry... a giant pile of fail. > But hey, think of all the jobs that would go away if things were designed right in the first place so you could just drop in a mass produced appliance. I'm pretty sure I'll retire first... -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] md_check_against_smtp_server and md_graphdefang_log
On Tue, Mar 26, 2013 at 9:02 PM, David F. Skoll wrote: > > Do they pay you to provide service? In principle, I agree with your > approach, but it's doomed to failure in the real world. The real > world is a mess and sticking to strict, pristine principles of email > delivery quickly means you'll have no paying customers. Besides which, real spammers are much more likely to take the trouble to set up SPF properly than an ordinary person who just wants to send you a message that you'd want to see. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] md_check_against_smtp_server and md_graphdefang_log
On Tue, Mar 26, 2013 at 1:20 PM, wrote: > > You may not agree but that is what the function is for per the author. > I agree that there are better ways (e.g. LDAP database) to do this than to > fake an SMTP transaction, aborting just before the DATA phase. When I first > saw this function years ago, I thought that its purpose was to make callbacks > to the sender's mailbox to test reverse deliverability, not to exclusively > test the primary MX's acceptability of the message from a secondary. It's not necessarily between a primary and secondary with public MX's. I found it very useful when the public MX's for a domain do not host the actual users but instead relay through a private firewall to a hidden internal delivery host. However the inbound spam rate eventually made it impractical - and I started maintaining virtusers tables with a default reject rule on the MX hosts that sendmail can process very quickly. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Email injection and the android 'email' app
On Tue, Mar 5, 2013 at 4:59 PM, David F. Skoll wrote: > > There's no way you should break your setup to comply with a brain-dead > Android app. > Is having a submission server that doesn't know all of the domain addresses necessarily broken? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Email injection and the android 'email' app
On Mon, Mar 4, 2013 at 11:30 AM, Dale Moore wrote: > > The android 'email' app, will NOT take this 'permanent' failure as definitive, > and instead try again shortly to resend the email. The email remains the > the app's 'Outbox' . I currently have dozens of remote android client > that connect to my smtp server that regularly attempt to send their > same mis-addressed email dozens of times a day for weeks on end. Those aren't big numbers and it shouldn't bother your server much even if they were orders of magnitude higher... Why not just ignore it? Or do you want to improve the user's experience by getting a DNS in their inbox where they might see it - which is what would happen if the server where they submit didn't know the user list? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Email injection and the android 'email' app
On Tue, Mar 5, 2013 at 2:00 AM, Andrzej A. Filip wrote: > On 03/04/2013 06:30 PM, Dale Moore wrote: >> [...] > > I would suggest combination of per "SMTP AUTH user" bounce settings > (possibly with auto change) AND scripted scanning logs for offenders. > > I hope you are not going to use another option mentioned without very > good reason/very hard pressure. Yes, consider what would happen in the more typical scenario of the authenticated 'submission host' server that you give out for your users _not_ knowing the user list for the domain. It is the somewhat accidental fact that yours does that triggers the problem, even if the problem really is in the submitting application. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] DSN Policy - was Re: Email injection and the android 'email' app
On Mon, Mar 4, 2013 at 1:00 PM, wrote: > --- On Mon, 3/4/13, Dale Moore wrote: >> ... I have had the philosophy that it is better to reject an email via >> SMTP protocol (550 5.1.1 No Such user here) instead of accepting an >> email then later sending a Delivery Status Notification (DSN) that an email >> could not be delivered > > I don't believe that one has such a choice. In today's hostile world, if one > CAN reject during the SMTP session, one MUST reject during the session. An > end system (where mail is delivered) should never generate a rejection DSN; > only relay systems may/should do so but not always (cf. forged mail). > > The fact that your belief is not absolute is indicative of the problem. But this isn't random spam here - the host in question is the submission host and the client in question isn't a transport relay. I agree that shouldn't really make a difference in terms of understanding the protocol, but maybe google really wants android users to use the gmail app. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] General Milter Questions
On Tue, Nov 13, 2012 at 7:37 AM, Kevin A. McGrail wrote: >> >> First of all if there is a better mailing list to send milter api related >> questions, please let me know. > > This is definitely not the mailing list for your questions. You are looking > for a sendmail or postfix milter devel list. > > This is the mailing list for one specific milter called MIMEDefang. On the other hand, you could probably do whatever it is you need in a few lines of perl using MIMEDefang and if you need to do operations during more than one delivery phase its design is likely to be more efficient than you would do by yourself. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] The .local TLD
On Sat, Aug 18, 2012 at 9:49 AM, David F. Skoll wrote: > On Sat, 18 Aug 2012 14:50:37 +0200 > Tilman Schmidt wrote: > >> Am 17.08.2012 21:35, schrieb David F. Skoll: >> > RFC 1918 addresses don't typically leak out onto the Internet, so > >> JFTR: Yes, they do. > > Maybe a hop or two because of misconfigured routers, but not typically > all the way to a root name server (unless your ISP is asleep.) Where do all the reverse DNS lookups go for the private-range IPs if you fire up a linux (etc.) name server without configuring it with your local ranges? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mail Admin Question
On Fri, Aug 17, 2012 at 2:09 PM, Ben Kamen wrote: > Curiosity question for Todd and Jon, > > At this point in the game with people moving to very web based mail > operation, are there any compelling reasons are there to stick with Exchange > in the future? (other than legacy setup and a new learning curve?) > > And have your companies considered moving to cloud services like Gmail? The mail part is easy - shared calendars and meeting scheduling have always been the big draw for exchange/outlook. Gmail might be getting close if the associated phones are running android. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Remembering lots of passwords (was Re: FYI: LinkedIn MIMEDefang group is gone)
On Wed, Jun 6, 2012 at 2:49 PM, David F. Skoll wrote: > > > Ah, I see. Being a curmudgeon who pines for the old days, I own no > Internet-capable mobile devices. :) I actually enjoy being unreachable > sometimes. I'm old enough to remember computing in the 'old days' as giant bundles of point to point serial cables with mostly-incompatible devices at each end, so I tend to enjoy the new toys that are both wireless and connected to everything all the time. And quick google searches have replaced most of my memory - neither one goes back as far as I'd like, though. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Remembering lots of passwords (was Re: FYI: LinkedIn MIMEDefang group is gone)
On Wed, Jun 6, 2012 at 1:57 PM, David F. Skoll wrote: > >> What is your secret to remembering hundreds of unique passwords? Or >> forgetting the old ones as they change? > > I use a password-keeper app called "TkPasman" (sadly no longer maintained.) > > It encrypts your password list using OpenSSL and a master password. Make > sure that's secure and that your password list is physically protected. Thanks - but I probably use at least a dozen different devices in the course of a day (win/mac/linux/android, at least) and am not very good at planning to be on the right one at the right time and worse, some are firewalled from each other. Is there some way to handle that without trusting them all to some random outside service? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] FYI: LinkedIn MIMEDefang group is gone
On Wed, Jun 6, 2012 at 2:06 PM, Kevin A. McGrail wrote: >> >> What is your secret to remembering hundreds of unique passwords? Or >> forgetting the old ones as they change? > > Multi-factored authentication to an encrypted storage system unfortunately. > Not writing them down is just not tenable. Is that something handy enough that you have access every time you want to get to your mail/facebook/linkedin/amazon, etc.? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] FYI: LinkedIn MIMEDefang group is gone
On Wed, Jun 6, 2012 at 1:19 PM, Kevin A. McGrail wrote: >> > In short, yes, LinkedIn had a breach apparently. However, if you use decent > passwords that are unique as any security person will extoll, the damage > should be highly limited. What is your secret to remembering hundreds of unique passwords? Or forgetting the old ones as they change? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Received headers in general
On Wed, May 23, 2012 at 1:49 PM, wrote: > >> I disagree. You are projecting your interpretation on the RFC authors. >> They say you MUST NOT reject a message for a bad trace header. It further >> says that one reason for bad trace headers is non-SMTP systems. It does >> not say it's OK to reject because of a bad trace header from an SMTP system. >> You're reading text that isn't there. > > Wrong. It directly states that we can't reject on the basis of trying to > enforce SMTP trace header syntax upon non-SMTP trace headers. That is all. No. The exact quote: "As another consequence of trace header fields arising in non-SMTP environments, receiving systems MUST NOT reject mail based on the format of a trace header field and SHOULD be extremely robust in the light of unexpected information or formats in those header fields." There is a justification, but no qualification at all on the MUST NOT reject. > As noted, I don't apply the stricter checks to non-SMTP-claimed messages, so > I am in fact following this section of RFC 5321. But you said you applied them to Exchange-originating messages, which is a non-SMTP environment. > > Precisely, and as spammers often generate non-compliant messages, a RFC 5321 > compliance filter installed into an MTA is a valid anti-spam measure. That doesn't match my experience. Spam senders are extremely sophisticated and much more likely to pay attention to the exact syntactic details than the big companies with the 'we don't follow standards, we make them' attitude. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Received headers in general
On Tue, May 22, 2012 at 7:41 PM, wrote: > > > Exchange and gmail claim SMTP transport but fail to follow the required > syntax. Exchange isn't natively SMTP, so that mail doesn't originate in an SMTP environment. And if you want to claim to know more about internet mail that google well, good luck with that. > RFC 5321 does not ban rejecting on that basis. It bans only the application >of SMTP syntax to non-SMTP headers. New requirements rarely/never mandate that you stop interoperating with existing behavior. As far as I know, the only time the whole internet was required to change something at the same time was Jan 1, 1983 when TCP/IP was standardized. Even if you wanted to believe that there was a mandate to reject, which there isn't, you would have to give the senders time to adapt to new requirements. A long time. > Where "MUST" is given, such means that there is something to enforce. That's not what MUST means. It applies to what _you_ generate. > I enforce it and get much less spam as a result. Well, no. Your own numbers did not show it as being an indicator of spam. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Received headers in general
On Tue, May 22, 2012 at 3:31 PM, wrote: > >> > Over 90% of the messages so rejected are clearly spam >> (i.e. sent to a spamtrap mailbox) or have other problems. >> >> That doesn't seem like a particularly strong metric to >> me. What's your overall spam/non-spam ratio? > > In 2012, 50% to date. My current count has 4 more spams than not. > In 2011, 70% spam to 30% not. I no longer have statistics for 2010 or > earler. I replaced my server with new hardware in February 2011. > > This counts only messages that make it to SpamAssassin scoring and are > therefore accepted by the server. Messages rejected by the MTA for any > reason do not get scored. For example, on some days, I have over 200 > connections (separate addresses) rejected due to not having forward-confirmed > reverse DNS entries on the incoming clients. So 90% spam is probably not unusually high for "all mail" - and I wouldn't consider finding some attribute on 90% spam, 10% non-spam email to be a particularly useful indicator that you should reject. Unless you like to reject just because you can. Per rfc760 and a concept assumed through the rfcs:: "In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior." -- Les Mikesell lesmikes...@gmail.com Mail to unknown users won't be in the above counts, nor will SPF-failed messages (rejected directly at the "MAIL FROM" SMTP state), etc. Of course, messages with malformed Received headers are rejected by the MTA and not in the count either. I do not greylist, but I do have a fake high MX entry that always tempfails. I do not retain my mail rejection logs for longer than a week and delete them after I have reviewed them so I don't have precise counts to share. > > I do note that more than 90% of my current spam is such because it's > addressed to my spamtraps directly. I've received only about 10 spams this > year which have made it into my inbox, and those were messages which received > sn SA score above my threshold but under 10. Most of the time, the score is > under 4 for non-spam and over 20 for spam, with this year's spam highscore > being 83 (and a fraction). > ___ > NOTE: If there is a disclaimer or other legal boilerplate in the above > message, it is NULL AND VOID. You may ignore it. > > Visit http://www.mimedefang.org and http://www.roaringpenguin.com > MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com > http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Received headers in general
On Tue, May 22, 2012 at 1:42 PM, wrote: > Over 90% of the messages so rejected are clearly spam (i.e. sent to a > spamtrap mailbox) or have other problems. That doesn't seem like a particularly strong metric to me. What's your overall spam/non-spam ratio? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] X-Auto-Response-Suppress header
On Mon, May 21, 2012 at 4:47 PM, wrote: > > 2) You still haven't said why I should accept any message which violates the > standards. Malformed messages should be rejected for precisely that reason > -- ALWAYS. 1) Why do you bother with email at all if you don't care about the content? 2) The standards you mention are internet standards (even though you seem willing to violate them yourself when it suits your purposes). . Much mail actually originates in proprietary systems that do not have exact mappings to/from the internet standard requirements. If you want to communicate with people on these systems, you have to deal with whatever the gateway systems do with the messages. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] filter_sender, authenticated or smtp (port 25) Connections
On Sat, Mar 3, 2012 at 2:03 PM, Philip Prindeville wrote: > > Well, that's wrong. Going to IANA, I see: > > http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml > > > urd > tcp > URL Rendesvous Directory for SSM > 465 > > > 465 has *never* been allocated to SMTP. Period. > > It was hijacked. > Hijacked is pretty strong wording - it was officially proposed, conditionally accepted, then later dropped: http://www.imc.org/ietf-apps-tls/mail-archive/msg00204.html I guess that's the way committees roll... -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.73-BETA-2 is available
On Thu, Jan 19, 2012 at 1:21 PM, David F. Skoll wrote: > >> "make install" still creates /var/spool/MIMEDefang with mode 0700, >> though, so people who need group readability will probably still have >> to manually chmod it to 0750 or something, after installing. > > Bah, never thought of that... what do you think of MIMEDefang chmoding > it on startup if the '-G' option is given? I'm not really crazy > about that idea... I might just document in the man page that you should > chmod /var/spool/MIMEDefang if necessary. What's the point of having groups if you don't give things group readability? Especially with the Red Hat style of putting every user in his own group by default so no one will have access by accident. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Only MX record is fake
On Fri, Nov 18, 2011 at 9:36 AM, Kris Deugau wrote: > kd6...@yahoo.com wrote: >> >> Any spammer stupid enough to try to send his spew forging this host >> name as the sender address will also face an SPF-RR "v=spf1 -all" >> (while those idiots still resolving ONLY TXT-RRs for SPF will get >> "v=spf1 +all"). > > Some "idiots" are still using DNS infrastructure that does not > support the formal SPF RR type. > > The current stock BIND package on RHEL5 (and any of the source-rebuild > derivatives), for instance... But to be fair, bind97 is also a stock package, just not installed by default. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] From Specific Address's
On Fri, Oct 21, 2011 at 9:44 AM, Aaron Enders wrote: > > You my friend are ingenious this worked perfectly the first time through, I > can't thank you enough. I do have one more piece to the puzzle I have a > question on... > > What filter part scans outgoing email? I would like to have all outgoing > emails sent to said domains copied also.. > All mail going through the machine is scanned. MimeDefang doesn't have a concept of 'direction'. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Domain canonifyin?g and RFCs
On Wed, Oct 19, 2011 at 11:04 AM, Joseph Brennan wrote: > > Check this though- section 5 of RFC 2821:-- > > The lookup first attempts to locate an MX > record associated with the name. If a CNAME record is found instead, > the resulting name is processed as if it were the initial name. If > no MX records are found, but an A RR is found, the A RR is treated as > if it was associated with an implicit MX RR, with a preference of 0, > pointing to that host. > > So prefer MX, and if there is no MX, an A record is an implicit MX. OK, > we all know this. > > But if a CNAME is found "instead"-- and this seems to imply, as RFC 1034 > also implies, that you can't have both CNAME and MX together-- then the > "resulting name" is processed. What's the "resulting name"? The result > of canonifying the CNAME to an A record? > > Similar in RFC 5321 section 5.1, without "instead":-- > > The lookup first attempts to locate an MX record associated with the > name. If a CNAME record is found, the resulting name is processed as > if it were the initial name. > > Both say that in the absence of an MX record, an A record is an implicit > MX record, but both do *not* say that a CNAME can be an implicit MX. So > we have a logical problem: > > (a) If there is a CNAME, there can't be an MX record. > > (b) If there is no MX record, a CNAME is not an implicit MX record. > > So where would mail go? A CNAME is an alias to some other name. It can't have a separate MX associated with the CNAME, but if there is one for the real name, the CNAME (being simply an alias) inherits it. And if there isn't an MX, the real name's A record is used as it would be if you had used the real name. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Domain canonifyin g and RFCs
On Wed, Oct 19, 2011 at 8:35 AM, Steffen Kaiser wrote: > > Bind v9.7.3 does bark as well, if a MX points to a CNAME, bind v9.3.4 does > not. > Isn't that a loop waiting to happen since CNAMEs would inherit any MX records associated with their related real name? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIME::Tools 5.501 has been released
On 2/23/2011 1:52 PM, kd6...@yahoo.com wrote: --- On Wed, 2/23/11, James Ralston wrote: But: if you release a new version of MIMEDefang that requires perl 5.10, then it means that we can't upgrade beyond the latest version that still works with perl 5.8, because we aren't even close to being able to deploy RHEL6 (which includes perl 5.10) on production servers yet. Your choice not to upgrade I see as your problem. But CentOS6 with the corresponding versions and likely a larger base isn't out yet. Those of us who keep current are running perl 5.12.3. Some people choose new bugs over old. Not everyone. Red Hat also distributes BIND 9.3.6, which is a pre-DNSSEC capable version of the name server, yet even the DNS root zone has been DNSSEC signed for 9 months. That should tell you something about RH. Red Hat backports fixes, so it doesn't make sense to talk about their version numbers without tracking what they have changed. Like perhaps mentioning a CVE number that they haven't addressed. But in this case that's not quite true either since the 5.6 update included bind 9.7. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] milter recipient check?
On 2/1/11 8:36 PM, kd6...@yahoo.com wrote: --- On Tue, 2/1/11, Les Mikesell wrote: Is there a way to hook a milter to check recipients only after sendmail has already rejected anyone that is not a local or virtual user or alias? I have a steady stream of dictionary attack addresses and have set up virtualusers with default rejects for the domains so sendmail can reject them quickly. But now I'm trying to run milter-greylist ahead of MimeDefang and it wants to process all the messages. I can configure it to also have a specific list of addresses to process but would like to know if there is a better way. Can the greylisting be done with MimeDefang alone in later processing steps, or is there a way to hook milter-greylist to run after sendmail has already rejected recipients that don't exist? I read your prior post - but my response is still "Why?" If sendmail has already determined that the recipient be rejected, what is the purpose of calling an additional FILTER to make a determination? The problem is that the way milter-greylist hooks in, it runs before sendmail rejects unknown users. And unless I maintain another copy of the valid user list in it's config, it won't be able to keep up with the bazillion messages to unknown users. What you want is LOGGING, not filtering. No, I want greylisting - there is still a substantial amount of spam to the valid addresses that greylisting will stop. But I don't want to waste time maintaining the state that greylisting needs for destination addresses that don't exist. This is not a MimeDefang problem. The question is, can MimeDefang do the greylisting better by itself in a later operation? Or is there a different way to run milter-greylist with it? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] milter recipient check?
Is there a way to hook a milter to check recipients only after sendmail has already rejected anyone that is not a local or virtual user or alias? I have a steady stream of dictionary attack addresses and have set up virtualusers with default rejects for the domains so sendmail can reject them quickly. But now I'm trying to run milter-greylist ahead of MimeDefang and it wants to process all the messages. I can configure it to also have a specific list of addresses to process but would like to know if there is a better way. Can the greylisting be done with MimeDefang alone in later processing steps, or is there a way to hook milter-greylist to run after sendmail has already rejected recipients that don't exist? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang - "Bounce" when really a SMTP rejection.
On 8/20/2010 2:06 PM, David F. Skoll wrote: Kevin A. McGrail wrote: To me, it's not a mis-naming. A bounced email is rejected. I.e. a bouncer doesn't let you in the club. Weeelll... to me, "bounce" connotes actually generating and sending a non-delivery notification. I agree with the poster that "reject" is better, but it's such low priority ATM that I don't care too much to change it. :) If you are talking about 'real' mail servers, a non-delivery notification is always generated, so the only difference is whether it is created on your server or the one trying to send to you. But most of what we try to reject isn't real mail from real mail servers so in practice there is a big difference. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] action_bounce html mail
On 7/13/2010 4:46 PM, tonj wrote: The fact that most spam messages contain HTML doesn't imply that most HTML messages are spam. You will have many, many false-positives. yes I know that but I'm not too worried and I do intend to bring in a whitelist. My server only handles my own mail, no-one elses so there's no great consequence. In my efforts to control junk mail I have to start somewhere and nothing ventured nothing gained. If it is just yours, why don't you have MD add something in the header and let procmail file it in a folder you can inspect/empty once in a while in case your preconceived notions about the importance of these messages turn out to be wrong - or your filter just has a typo? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] action_bounce html mail
On 7/9/2010 3:13 PM, - wrote: Aside: --- On Fri, 7/9/10, Joseph Brennan wrote: You're going to reject a lot of mail. I wouldn't do this [reject html-only mail] even just for myself. Why? I've been doing that for years (since 2002). Per a review of my server logs, only people I don't know send me HTML mail (i.e. spam). However, I use a custom header rule in sendmail, not MD, to reject such. I also have in the ruleset the ability to check the sender against my "access" database and whitelist certain HTML senders if I choose. 90%+ of all HTML in e-mail is unnecessary. Only rarely does it add any value to the content or its display. I guess that all depends on what you want to see... I could say that about 90% of the text I receive too, but I can't afford to ignore it. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] patches/support of off-server clamd implimentation? (fwd)
On 5/24/2010 4:56 AM, John Nemeth wrote: Perl 5.8 is ancient. It was released in July 2002. CPAN says that versions prior to 5.8 are unsupported. Most people are using 5.10 which was released in December 2007. I highly doubt that. RHEL5.x/CentOS5.x have 5.8, albeit with some backported patches. And they'll be running into 2014. And, for people that want to work on the bleeding edge, 5.12 was released in April 2010. Your systems are out of date by almost eight years! It is completely unreasonable to expect anybody to support such ancient systems. Actually it is hard to support fast-changing systems, hence the 'enterprise' linux distributions that try to make sure things aren't bleeding-edge. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
David F. Skoll wrote: > There is no need for you to know who the ultimate enduser composing the e-mail is. I don't want to know who the ultimate end-user is. I just want to know the IP address of the machine that injected the email into Google. It's a valuable of information I can use in my filter. How can it possibly matter if my laptop is sending from a Panera Bread hotspot or a hotel room where it hasn't been before and probably won't be again? Any decision you make based on that information is almost certainly going to be wrong or biased by unrelated things done by other people at some other time. The relevant piece of information is that I authenticated to the server that sent the message. -- Les Mikesell lemikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 3:59 PM, David F. Skoll wrote: The RFC defines a gateway as this: A "gateway" SMTP system (usually referred to just as a "gateway") receives mail from a client system in one transport environment and transmits it to a server system in another transport environment. Unfortunately, a "transport environment" is not defined by the RFC. I consider submission via HTTP to be sending mail over a transport environment. I think it's a reasonable interpretation, but alas... the RFC doesn't say. We are obviously not going to agree here but a few more data points: using the OWA interface (outlook web access) to an exchange server does not add a Received: header for the browser client IP. Likewise when sending from outlook 2003 or 2007 (much more believable as mail clients) through exchange, the first Received: header is the server's. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 1:47 PM, David F. Skoll wrote: (Why do I get sucked in? :)) Because you would be equally pedantic if you thought someone else was misinterpreting and abusing an RFC... No. You misunderstand. The web *server* is the email gateway. It gateways mail *from* the browser (using HTTP) *to* the Internet (using SMTP). Gateways need something on both sides to participate. Yep. On one side: The Web browser. On the other side: The rest of the Internet. Why is that so hard to understand? It is not a non-internet mail system running inside my browser - which is what the RFC covers. No. It originates as email from withing the browser. You may claim it's some black-box blob of data, but everyone who uses webmail will disagree. Stop someone and say "What are you doing?" He/she will say "Writing an email", not "filling in a form that the browser carries blindly and that turns into an email on the server." No one thinks they are using a non-internet email system that runs inside their web browser or on their own machine - unless maybe they'd think facebook runs inside their laptop too. And if you ask Joe Brennan what he's doing, he'll say "Composing an email on machine x.y.z.w that's running Pine". And if you ask a knowledgeable Thunderbird user with a remote X display what he's doing, he'll say "Composing an email in Thunderbird running on machine x.y.z.w." It's clear to everyone where the real action is happening. Just as clear as it is that there is no mail system running inside my browser and no gateway operation from one mail system to another happening as I post. A person who would understand thunderbird running remotely would equally understand that gmail does not run on his local machine. Partly both I suppose, but I don't like people interpreting RFC's oddly to support their own agenda, You and Gmail are the only ones with this interpretation. Other Webmail providers (Yahoo, Hotmail) and Webmail software (Squirrelmail; Horde) use my interpretation. So I submit that you are the one interpreting the RFC oddly. Just because they add a header doesn't mean an RFC requires it - or at least not that RFC. Here's the thing: Between the Google Webmail server and the client's Web browser, there is an interface between two administrative domains. Google doesn't own the Web browser (yet!), but it does own the Web server. For tracing purposes, it is desirable (I would say mandatory) to track the flow of email across this interface. I don't necessarily disagree, I just don't think the gateway-related RFC applies here. Generally speaking, between an X client and an X server, or between an SSH client and an SSH server, there is not an interface between two administrative domains. So apart from the fact that the SMTP gateway *cannot* report the client's IP, there's *no need* for it to do so. (If people started offering public-access Pine-over-SSH or public-access Thunderbird-over-X, I would change my position.) I have an ssh account on a remote machine under approximately the same terms as my gmail mail account. I don't see any point here or any difference in originating mail from a program on that machine or the gmail program displaying in my web browser. They both originate under my credentials on the remote server and have no relationship to the keyboard where I'm typing. As an email admin you have the right to discard email whimsically. It's not whimsical at all. Google is suppressing critical information showing the flow of email from one administrative domain to another. This is purely evil and utterly unjustifiable. OK, but that is unrelated to the RFC - and a matter of opinion since it is really a remote display from the administrative domain where the mail originates. Anyway, I don't like web mail interfaces and almost never use it to access gmail. How do you process mail that came through a gmail account from a user interface that submits via SMTP where the appropriate Received: line is added (coming from thunderbird, I see both my private and NATted address in there)? If you drop that, who is doing the evil and unjustified thing? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 12:56 PM, David F. Skoll wrote: Transmitting an email via HTTP from a client computer qualifies as gatewaying by my reading of the RFC. That means you have to think my web browser is also an email gateway. No. You misunderstand. The web *server* is the email gateway. It gateways mail *from* the browser (using HTTP) *to* the Internet (using SMTP). Gateways need something on both sides to participate. If it isn't email inside the browser (and it isn't, it is a form that the browser displays mindlessly and http carries blindly), how can it be a gateway operation? It originates as email from the web application on the server with the user's credentials. The browser displays a form, but only the application at the other end knows anything about the contents being mail. Which is exactly the same scenario as if I typed it into thunderbird in a remote X window. I can't tell if you're baiting me or deliberately being obtuse, so I think I'll withhold further replies. Partly both I suppose, but I don't like people interpreting RFC's oddly to support their own agenda, and I don't see how anything a browser does can be considered as any more than a remote display for a server side application. As an email admin you have the right to discard email whimsically - you don't have to interpret RFC's imaginatively to justify it. If that RFC had been intended to cover remote displays or web forms it could have said so - web interfaces were pretty well understood by then. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 12:05 PM, David F. Skoll wrote: Because running pine over SSH is not a "gateway" as defined in RFC 5321, whereas running a Webmail server that accepts email using some kind of transport (HTTP or HTTPS) and then delivers it using SMTP *is* a gateway as defined in RFC 5321. Sorry, but a web interface isn't an email gateway. Transmitting an email via HTTP from a client computer qualifies as gatewaying by my reading of the RFC. That means you have to think my web browser is also an email gateway. I don't see any reason to think it is more than a display transport. The application running email isn't where the web interface displays it any more than it would be if you display thunderbird in a remote X session. No, that's not correct at all. Using HTTP as a transport protocol for email is quite different from using the X protocol to draw pixels on a remote display. How so? X does more than draw pixels, but neither X nor http know anything about email or the contents of what they transport. That's all up to the application at the other end - and it's why they are both so useful. But the RFC says nothing about remote displays and remote application acccess, whether provided by ssh, X, or http(s). The RFC defines a gateway as: A "gateway" SMTP system (usually referred to just as a "gateway") receives mail from a client system in one transport environment and transmits it to a server system in another transport environment. This describes webmail exactly. You type your email into a form in the Web browser which transmits it over HTTP to the server. That's the server "receiving mail from a client system". The browser displays a form, but only the application at the other end knows anything about the contents being mail. Which is exactly the same scenario as if I typed it into thunderbird in a remote X window. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 10:07 AM, David F. Skoll wrote: Les Mikesell wrote: How is running pine on a remote machine any different than running a web interface to mail, perhaps on that same remote machine? Because running pine over SSH is not a "gateway" as defined in RFC 5321, whereas running a Webmail server that accepts email using some kind of transport (HTTP or HTTPS) and then delivers it using SMTP *is* a gateway as defined in RFC 5321. Sorry, but a web interface isn't an email gateway. The application running email isn't where the web interface displays it any more than it would be if you display thunderbird in a remote X session. Maybe you think it's splitting hairs, but we have to abide by the RFC, which is abundantly clear. But the RFC says nothing about remote displays and remote application acccess, whether provided by ssh, X, or http(s). My web browser knows nothing about mail and there is no gatewaying of email going on between it and gmail - it just displays what the remote app wants it to. Any concept of 'mail' starts on the server side - and is tied to the login on that remote system. Yes, you could pervert this to originate mail with a remote program, but you could do the same over ssh/pine (or a serial port for that matter), equally tied to your credentials on the remote host where the mail activity actually happens. I wouldn't object to showing the remote display's IP address in a header so I'm not arguing against that, but it is somewhat imaginative to think a web browser is the other half of an email gateway so the RFC requirement would apply. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 8:47 AM, David F. Skoll wrote: So... I would say that gmail.com is violating a MUST requirement of RFC 5321. Here's something similar. When I log into a timeshare and send mail with Pine, you don't get to see the ssh hop from my Mac either. There's no email gatewaying going on between your Mac and Pine. And the IP address of the Pine box is sufficient to determine the organization (maybe even the person) responsible for originating the mail. How is running pine on a remote machine any different than running a web interface to mail, perhaps on that same remote machine? The real app is on the server side and the fact that it is displayed remotely doesn't have much to do with the mailer. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] watch-mimedefang
On 2/16/2010 1:37 PM, Cliff Hayes wrote: I can ssh from my windows instance of cygwin to the mimedefang server. I also established a trust relationship by exchanging ssh keys. I do that all the time to automate ssh tasks. However, for cygwin, it keeps defaulting to my windows user and not "root" and that's the problem. Are you doing this from one of the xterms that started when you did a 'startx'? You shoud be the local windows user there. And you probably have to have run the mkpasswd and mkgroup commands as shown when you installed cygwin so you'll have a home directory for the .xauthority file. I can override it if I type out the ssh command at the command prompt (ssh root@) but when watch-mimedefang runs, it uses the windows user. That doesn't make any sense if your ssh command actually worked - you should be root on the remote side. But either you have to permit password based logins or you have to have set up the keys for the windows user at your end and root at the other. And you should add the -P option to the ssh command line to make sure the X tunneling works. If I could figure out how to run cygwin with root user I think it would work. I just did it on my laptop and it worked as expected - with the cygwin side running as my windows user id but logged in as root on the server. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: Choice of desktop OS (was Re: watch-mimedefang)
On 2/16/2010 10:33 AM, Ben Kamen wrote: On 2/16/2010 10:02 AM, Les Mikesell wrote: Windows 2000 is a decade old now - and was not even intended to be a desktop OS. And you need to defrag after making big disk changes. If you don't already see why this is a bad comparision, try installing a 10-year old Linux server distro and try to update it to a current desktop piecemeal. So what MS gives us now is a modern OS in which they STILL patch regularly to fix things that should have been fixed a long time ago As does every supplier of complex code. It's a feature. (and I'm not saying Linux is immune, but there's a level of pride for producing solid code that comes with the personally driven contributers of the OSS community than any company worried about the bottom line.) I take it you don't read the changelogs on linux distribution updates to see the historic bugs that are still being found and fixed. You should. But even more offensive is the level of control that was attempted in Vista that has lost its fanfare and is probably successfully implemented into Win7. (and now with MS inserting the new version of WGA which caused a lot of false positives last time in a fashion even more deceitful than that with WGA.) As an example: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html Sigh. Vista is irrelevant. If you read any trade literature at all you would never have touched it in the first place. Just like any X.0 version of a linux distribution. But realistically, the problem in Vista was changing the driver interface, something that Linux does with every re-compile and enterprise distributions have to work around by backporting some of the updates into old kernels without breaking them. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: Choice of desktop OS (was Re: watch-mimedefang)
On 2/16/2010 8:45 AM, wbr...@e1b.org wrote: The frustration of having to run a Windows desktop would drive me insane. Making the switch caused some grief, but I think it was worth it in the long run. If nothing else, patches don't eventual bog the system down like they do in Windows. If you don't believe me, take a fresh machine and install Windows 2000 on it. Time how long it takes to boot. Then do nothing but patch it. Alot. Reboot repeatedly. Burn most of a day doing so. Time how long it takes to boot after all current patches are applied. Last time I did this, it took about 3 times longer to boot. Windows 2000 is a decade old now - and was not even intended to be a desktop OS. And you need to defrag after making big disk changes. If you don't already see why this is a bad comparision, try installing a 10-year old Linux server distro and try to update it to a current desktop piecemeal. Now when my laptop takes longer to boot, it's because I added something. With windows XP, windows 7 or OSX on a laptop, you generally close the lid to sleep, open again to wake up nearly instantly with local networking established automatically and they've done that well for most of a decade - so you rarely need to reboot. It's possible to make some of the current linux distros do this if you are lucky, but it's not a given. Having said that, I prefer Linux on servers, but I'm perfectly happy to run the screens remotely with freenx/NX (easier than fighting with distros that don't included Nvidia drivers anyway) and to test experimental stuff under VMware where it is irrelevant what OS is hosting natively. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] watch-mimedefang
Cliff Hayes wrote: Les Mikesell wrote: It is fairly difficult to imagine a box that is still running today that couldn't handle a GUI The 42 servers I manage range in age from old to new, Fedora 4 thru 12, ubuntu, and Windows. None will ever see a "user" who would benefit from a GUI ... only me remoting in to tweak/repair. The server themselves don't need a GUI - but having one on the machine where you have tools to manage them will make your work easier even if all you do is run a bunch of xterms with ssh to the others. > IMHO GUIs are great for users but unnecessary overhead on servers. Three of the boxes are Windows so I have no choice there. I must be in the minority since there appears to be no call for a web version of watch-mimedefang. The nature of X is that you can run single applications in a remote window, so all you need on the servers are the basic X libs, and they are only loaded when you run a graphic application. The real overhead is in the desktop environment which can be elsewhere. I'll have to give up on the cgywin as it took half a day (and 1G of hard drive space) to attempt to set up the logistics for it and I still can't establish the ssh relationship necessary for it to work. Most of the time goes into building and installing all the local fonts. How did it fail for you? Did 'startx' give you the X screen with some open xterms? Could you 'ssh -Y' to your server from one of them? If you got that far, starting a remote program should have worked. You should even be able to use putty on the windows side if you set up the X tunnel option - I've forgotten if you need to set up the DISPLAY environment. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] watch-mimedefang
Michael Sims wrote: Cliff Hayes wrote: For this idea, don't I have to have a GUI OS installed on the linux box I'll be remoting into? I did a test install on a spare Ubuntu box I had here, and yes, when I ask apt to install vnc4server, it wants to pull down a ton of packages, including several xserver* ones. So if a small footprint on the server side is important to you this may not be the route to go... You need to have the X code and window manager installed but not necessarily running on the console. It is fairly difficult to imagine a box that is still running today that couldn't handle a GUI, seeing as how virtually everything shipped in the last 15 years has been designed for, and usually shipped with MS windows. If you are running something that old/limited, I'd recommend replacing it with a VMware guest on some more modern box and saving some power. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] watch-mimedefang
Cliff Hayes wrote: Thanks. I'd like to start with the cygwin idea. I am in the process of loading cygwin. I tried the default load and apparently that was insufficient to run watch-mimedefang. So, I added the whole X11 section and it's been downloading for an hour (I have a fast connection). I feel like I'm downloading half the Internet. Is there certain packages I need for cygwin to work? I tried to look through the list looking for tcl/tk but didn't find anything that looked promising. You'll need a full X server and some sort of window manager. Xming might be an easier install but it's basically all the same. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] watch-mimedefang
Michael Sims wrote: In addition to the suggestions others have made, you can also install VNC server on your linux machine (most distros have a package for it) and use a VNC client from your Windows machine to connect to it. You can run multiple displays within the VNC server (each one for different users if you like) and the sessions will stay persistent even after you disconnect with your VNC client. I usually find this is the simplest way to run X programs from Windows since most admin types running Windows have a VNC client installed already... Yes, vncserver works pretty well if you have a fast local connection - and it is easy to set up. The freenx, NX client combination does approximately the same thing but is much more efficient because it uses X protocol instead of just bitmaps - and it can resize the screen as you connect from different clients. It also tunnels everything over ssh so you don't have to arrange that yourself. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: Choice of desktop OS (was Re: watch-mimedefang)
Tilman Schmidt wrote: Am 13.02.2010 00:54 schrieb David F. Skoll: I must confess, I've never understood people who administer Linux servers, yet don't run a Linux desktop. Heck, run Linux in VMWare if you must, but at least use proper desktop tools to administer a Linux server. From personal experience I can recommend doing it the other way around: run Windows in VirtualBox on a Linux desktop. Although that can be done on some models, I've had trouble getting all the device drivers and sleep mode to work as well as the windows or OSX that came installed. But if you have a stable linux server to host your desktop session, freenx on the server side and the NX clients from http://www.nomachine.com will let you run remotely regardless of the local OS and, depending on what you are doing, often with better performance than running a copy on a laptop. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] watch-mimedefang
On 2/12/2010 4:54 PM, Cliff Hayes wrote: Thanks. I don't have any linux servers with GUIs. Will it work with Windows? Yes, if you install a Windows X server - the free cygwin one will work. However, if you do much linux work, I'd recommend something slightly different. Pick a linux box near the servers - perhaps one where you do testing and development and install the 'freenx' package. Then install the NX client from www.nomachine.com on your windows desktop(s). This lets you run a complete Linux GUI desktop remotely in what appears to windows as a normal window so you get cut/paste between systems, etc. Besides being easier to install than most windows X packages, this also lets you disconnect the session and pick it up with everything still running, perhaps from a different client, and it is very efficient over low bandwidth connections. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] watch-mimedefang
On 2/12/2010 3:26 PM, Cliff Hayes wrote: Hello, I am using GraphDefang. In looking at the sample output from watch-mimedefang I see it provides more details. I have not been able to use watch-mimedefang because it's a GUI. If possible, I'd like to start using watch-mimedefang. I run mimedefang on a fedora 11 server. I never load OS GUIs on any of our servers as the overhead is not necessary. Will watch-mimedefang work from the console? I understand it requires Tcl/Tk to work. However, a yum search of such packages returns 188 results. What are the prerequisites for watch-mimedefang? X programs don't need to display on the same machine they run. If you just have the basic X libs installed you can 'ssh -Y' from a desktop elsewhere to the server in question and run watch-mimedefang (or pretty much any X program) and it will open a new window on your desktop to display. -- Les Mieksell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] mimedefang letting some spams through...why?
On 2/3/2010 2:19 PM, - wrote: --- On Wed, 2/3/10, Tony wrote: ... ok thanks for this info David, I appreciate it and it makes things clearer. Based on what you say I will leave things as they are ... NO! By leaving it, you're scanning TWICE (or more). You're not fixing the problem. Now that he has MimeDefang rejecting matches, he's only scanning the non-spam messages twice, though... -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] auto reply / vacation
Tilman Schmidt wrote:
--- On Mon, 2/1/10, ml ml wrote:
has anyone got some hints for me how to write a auto reply /
vacation script? Or is there already such a project out ...
Yes: DON'T. There are enough problems with existing autoresponders out there.
well, there is the feature request which needs to be done. So there is
no way around it.
In my experience, there is almost always a way around unreasonable
feature requests, although it typically involves hurdles such as
actually talking to the requestors.
What problems exactly, how can they be avoided?
Firstly, using an autoresponder very rarely serves any useful purpose.
In many cases it actually harms, for example by leaking internal
information (such as the existence of the mail address, the real name of
its owner, or the reason and/or duration of his or her absence), creates
false expectations ("will reply promptly after my return" :-) and/or
annoys the recipient ("why is no one filling in?").
Secondly, autoresponders frequently respond to mails they shouldn't,
such as mailing lists, newsletters, SPAM, "do not reply" mails, machine
generated notification mails, DSNs, mails from other autoresponders ...
Reliably avoiding that is very hard.
Thirdly, autoresponders may send their autoresponse to the wrong
recipient. It's of course not always obvious who the correct recipient
of an autoresponse should be or how to determine that algorithmically.
Fourthly, the autoresponse is often useless to the recipient. I
regularly receive automatic "I have received your mail and will reply to
it promptly" messages which don't give me any clue to which mail they
might refer to, and from mailboxes to which I never consciously sent a mail.
And fifthly (does that word exist?), autoresponders interact badly with
another nuisance "feature request", legal disclaimers. The autoresponder
emits a canned message that doesn't give a clue to whom it might be
addressed and what it might referred to, and the attached disclaimer
then asks the recipient to "delete all copies of the message" if he or
she is "not the intended recipient". What kind of impression will the
recipient of such a message get about the legal and technical competence
of the organization that was responsible for the emission of such an
incoherent piece of mail?
On the other hand, there are people who use email regularly in situations where
it is useful to know that the recipient is away and, if they want to provide
that information, when they will return. But, the feature really needs a way
for the user to provide the input and might not be possible in Mimedefang
running on an internet gateway. On unix-like systems where it is possible to
forward to a program with a .forward file in the user's home directory it is
done with a program called 'vacation', and the 'usermin' (an offshoot of webmin)
can be used as a web interface to manage the setup if people don't ordinarily
log in directly to the mail server. It is important to get several things right
in a program like this (don't respond more than once, don't respond to mail list
messages, etc.), so be sure you know what you are doing if you have to reinvent
this wheel.
--
Les Mikesell
lesmikes...@gmail.com
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Sendmail::Milter
- wrote: --- On Tue, 11/24/09, Joseph Brennan wrote: One connection per 5 minutes is extremely low. You are aware that this is one connection per 5 minutes PER IP ADDRESS, aren't you? (Not one connection from anywhere every 5 minutes) For those of us that get a lot of mail that sounds like an insane restriction. Even if you don't have users on mail lists, here's a likely scenario: someone sends you (or your boss) an important message with a mistake, realizes it and sends the corrected version immediately. You receive the mistake, block the correction, and the revised version gets queued till tomorrow while you are acting on incorrect information. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Sendmail::Milter
- wrote: --- On Tue, 11/24/09, Les Mikesell wrote: ... Which would only happen if they tried to open two separate TCP sessions within the 5 minute window. Which will almost certainly happen regularly if anyone joins a mailling list that is slightly busier than this one. That's why they aren't immediately thrown to the TCP TARPIT. A mail server that had just connected and delivered its message(s) should be drained and therefore have nothing else to deliver until it receives something else, and then, if it can't "hold its wad", that's not my problem. We all know that spammers can't hold their wads and this is what the ruleset was designed to combat. Some mailers deliver multiple messages per connection, some don't. Some mailing lists get more than one message per 5 minutes and attempt delivery of each immediately. Blocking connections hitting you at several per second might make sense to fight spam (but the good spammers will be coming from hundreds of different but coordinated IP addresses), but a few messages a minute is perfectly normal traffic. Mail isn't "instant messaging." If they get a connection refused (the ICMP admin-prohibited msg) and can't wait at least 2.5 minutes before retrying (as I do issue 2 ICMP warnings), they are probably a spammer. A properly behaving mail server would queue the message and try again at its next queue interval (usually >= 5 minutes). If they can't deliver multiple messages but just one per connection, they need to wait 5 minutes before trying the next. If you don't care if or when mail is delivered, why run the server at all? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Sendmail::Milter
- wrote: --- On Tue, 11/24/09, Tilman Schmidt wrote: Am 2009-11-23 21:38 schrieb -: I too limit connections to one, and one per 5 minutes. Should remotes violate that, they get two warnings (ICMP admin-prohibited), and if they're too eager, they fall into my TCP TARPIT. I wonder. Do you have any data on how typical mail server software reacts to that sort of policy? What does, for example, a Sendmail or Exchange server in default configuration do if it tries to deliver two mails to a destination server, the first one succeeds, and the second one fails with "administratively prohibited"? Which would only happen if they tried to open two separate TCP sessions within the 5 minute window. Which will almost certainly happen regularly if anyone joins a mailling list that is slightly busier than this one. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Sendmail::Milter
Andrzej Adam Filip wrote: Tilman Schmidt wrote: Am 2009-11-23 21:38 schrieb -: I too limit connections to one, and one per 5 minutes. Should remotes violate that, they get two warnings (ICMP admin-prohibited), and if they're too eager, they fall into my TCP TARPIT. I wonder. Do you have any data on how typical mail server software reacts to that sort of policy? What does, for example, a Sendmail or Exchange server in default configuration do if it tries to deliver two mails to a destination server, the first one succeeds, and the second one fails with "administratively prohibited"? AFAIK sendmail does not distinguish between reasons why establishing TCP connection have failed. Have I missed something? Any reasonable smtp mailer will handle a connection failure by retrying any other MX listed in DNS and if none succeed, queuing for subsequent retries. It doesn't make a lot of sense to limit at rates that that aren't a threat to your service unless you have a dictionary attack with mostly invalid recipients (which sendmail already knows how to throttle). Otherwise you'll just back up mailing lists. -- Les Mikesell lesmiks...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Message header madness - was Re: SPF Usefulness (was Re: SNARE spam detection)
- wrote: --- On Fri, 7/31/09, David F. Skoll wrote: Outlook's explanation is wrong. From RFC 2822: I know it's not as precise as it should be, but remember we're dealing with Microsoft - a delusional company that regularly thinks it can do its own thing and everyone else will conform to them. but I stand by my view that a positive value (toward spaminess) should still be assigned when it is identical to the "From" header value. That's not my experience. For some spams, especially phishing spams, Reply-To: is very different because the sender wants to trick the recipient into replying to a throwaway address even if the purported From: address looks official. Considering that the Reply-To header is supposed to be different than the From header, the difference itself isn't significant information. Now, WHERE that reply-to redirects replies is significant info., especially when the domain part of that mailbox is repeated in a URL in the message body. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang These list messages fit your description of a REPLY-TO: with a domain matching a URL in the body (as would one from David if the list didn't change the reply-to, as some don't). What significant information can you deduce from it? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking Dictionary Attacks
Paul Murphy wrote: afo cliff 09/06/2009 17:18 >>> Ok, then it looks like it's better to stick with access/virtusertable rejection. No, it is infinitely better to do it in filter_recipient, and terminate the connection after a number of invalid recipients. Consider the case where a spammer connects and tries a list of 2000 common accounts (root, postmaster, admin, daemon, staff, info, etc...). Rejecting via the access DB will reject all of the ones which are invalid, and will do so quickly. However, all of the valid ones will get the spam, and the spammer will also get a 2xx OK code to that recipient, so they can tune their mailing lists to remove known bad addresses, and sell on the ones which they now know to be working. Spammers are a lot smarter than that these days. If you watch your logs during a dictionary attack you are likely to see the messages come in from dozens of different IP addresses that are obviously coordinating the address space and timing so you don't see a big number of addresses come in from any single source, or on any single message, or fast enough to overwhelm a reasonable server. Doing it via filter_recipient, the spammer sends RCPT_TO with the first address, which might be valid. However, long before they have gone through the 2000 in their list, you've seen 3 bad addresses, and have rejected the whole message. Sendmail can do this directly as well: define(`confBAD_RCPT_THROTTLE',`3')dnl And unless you expect messages with a large number of recipients you can refuse to accept them without running any perl code: define(`confMAX_RCPTS_PER_MESSAGE',`5')dnl 'Real' senders are supposed to figure this out and resend but I don't know how it works out in practice. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking Dictionary Attacks
Matt Garretson wrote: afo cliff wrote: Thanks for the info. It mentions using the -t flag ... however, I start mimedefang with "service mimedefang start" so I don't have any control over the flags that are being used. It sounds like you have Fedora or a Redhat variant? There should be /etc/sysconfig/mimedefang which you can edit as you like. But, if you have defined everyone in virtusertable with default rejects, sendmail will process invalid recipients faster than mimedefang can. You might still get a few instances where where a message comes in with a large number of invalid recipients that makes it obvious spam but it will still be accepted for a small number of valid addresses. You might be able to figure that out with some work in filter_recipient - or just hope that your other checks catch it. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking Dictionary Attacks
afo cliff wrote: Matt Garretson wrote: afo cliff wrote: @mydomain.com bitbucket You can also do something like this in your virtusertable: @mydomain.com error:5.1.1:550 User unknown Then, you won't need the bitbucket alias. See http://www.sendmail.org/m4/features.html Yes thanks, I tried that, the down side for me is that it sends a "User Unknown" reject notification, which I'm trying to avoid. I don't want my server to waste time sending 10,000 rejects to a zombie somewhere. You have that backwards - it's much, much faster to send a '5xx' failure response in the SMTP conversation before accepting any data. Also, by accepting, you'll convince the sender that the addresses are legitimate and they'll end up on lists that are re-used for years - but it is probably already too late for that. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking Dictionary Attacks
Jason Bertoch wrote: -Original Message- From: mimedefang-boun...@lists.roaringpenguin.com [mailto:mimedefang- boun...@lists.roaringpenguin.com] On Behalf Of Les Mikesell Sent: Monday, June 08, 2009 10:44 AM To: mimedefang@lists.roaringpenguin.com Subject: Re: [Mimedefang] Blocking Dictionary Attacks Matt Garretson wrote: afo cliff wrote: @mydomain.com bitbucket You can also do something like this in your virtusertable: @mydomain.com error:5.1.1:550 User unknown Then, you won't need the bitbucket alias. See http://www.sendmail.org/m4/features.html Yes, that approach will be much faster - sendmail will reject everything early unless it has a valid recipient and it won't have to go through the mimedefang spam/virus scan. I seem to recall that enabling FEATURE(delay_checks) was recommended as part of the MIMEDefang setup. It does provide much more useful logs, but I believe it also means that milters are run before virtuser rejects. I thought it would only delay until after RCPT TO: (so you'd run filter_relay, filter_sender, filter_recipient functions in mimedefang if you have them) but still before DATA where the heavy lifting is done. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking Dictionary Attacks
Matt Garretson wrote: afo cliff wrote: @mydomain.com bitbucket You can also do something like this in your virtusertable: @mydomain.com error:5.1.1:550 User unknown Then, you won't need the bitbucket alias. See http://www.sendmail.org/m4/features.html Yes, that approach will be much faster - sendmail will reject everything early unless it has a valid recipient and it won't have to go through the mimedefang spam/virus scan. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking Dictionary Attacks
Andrzej Adam Filip wrote:
That's a great idea! I tried it but no matter what I do, sendmail is
letting everything through. Virtusertable is configured correctly in
sendmail.mc, also did the appropriate makemap. I think something has
changed in sendmail (I have 8.13.8). I've searched the world over 10
times and tried many different combinations in virtusertable &
mailertable and no matter what it relays everything. I know it is
looking at the virtusertable because sendmail lets me know if I put an
error in the file. The closest I can come is to use the access table
in a similar fashion. That does work but I can't find a way NOT to
send a reject message. That's one thing I don't want to do is to tie
up my server sending 10,000 rejects to a zombie somewhere. If I use
the DISCARD command, then it tosses the whole email and nobody gets
it, even valid users.
Is there some trick to making your suggestion work?
In my case the MX server relaying in from the internet is not itself
the delivery host. It has the domains it receives for listed in
local-host-names and the actual delivery destination is mapped in
mailertable like:
domain.com esmtp:[host.domain.com]
(the []'s let you go to a name with an A record or an IP instead of
the default MX lookup)
mailertable is *NOT* consulted for domains listed in list of local email
domains ($=w, local-host-names).
Hmmm, I guess my virtuser table maps u...@domain to u...@host.domain and
it is actually the host.domain mailertable entries that work - or they
work without special lookups.
Maybe you don't have the domain listed in local-host-names so sendmail
thinks it must relay. Virtual users and aliases are only checked for
the domains it process as local - but you can still relay for
delivery.
virtusertable is consulted for local email domains ($=w) and
(non local) domains listed in $={VirtHost}.
Read carefully about side effects before using macros porviced by
sendmail.org for filling $={VirtHost}.
You can fill $={VirtHost} "directly":
LOCAL_CONFIG
C{VirtHost}example.net
P.S.
The topic has been discussed a few times plus in news:comp.mail.sendmail
Search for the threads with _VIRTUSER_STOP_ONE_LEVEL_RECURSION_
[it marks one recipe but you will find references to other by the way]
I set everything up with the macros in sendmail.mc on a CentOS system.
I used to use MAIL_HUB for what I considered the 'main' domain with
mimedefang validating the recipients via smtp, but a virtuser table
lookup is much faster (at the expense of having to maintain the mapping
table).
--
Les Mikesell
lesmikes...@gmail.com
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking Dictionary Attacks
afo cliff wrote: Les, That's a great idea! I tried it but no matter what I do, sendmail is letting everything through. Virtusertable is configured correctly in sendmail.mc, also did the appropriate makemap. I think something has changed in sendmail (I have 8.13.8). I've searched the world over 10 times and tried many different combinations in virtusertable & mailertable and no matter what it relays everything. I know it is looking at the virtusertable because sendmail lets me know if I put an error in the file. The closest I can come is to use the access table in a similar fashion. That does work but I can't find a way NOT to send a reject message. That's one thing I don't want to do is to tie up my server sending 10,000 rejects to a zombie somewhere. If I use the DISCARD command, then it tosses the whole email and nobody gets it, even valid users. Is there some trick to making your suggestion work? In my case the MX server relaying in from the internet is not itself the delivery host. It has the domains it receives for listed in local-host-names and the actual delivery destination is mapped in mailertable like: domain.com esmtp:[host.domain.com] (the []'s let you go to a name with an A record or an IP instead of the default MX lookup) Maybe you don't have the domain listed in local-host-names so sendmail thinks it must relay. Virtual users and aliases are only checked for the domains it process as local - but you can still relay for delivery. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking Dictionary Attacks
afo cliff wrote: Thanks Matt ... now I'm makin copies :) I need to have a way to stop dictionary attacks ... unless there is a better way I was going to extract the TO address and discard the email in mimedefang-filter if the user did not exist when compared against a database table of valid users. I'd be interested to know the preferred way to handle this. If you are going to maintain the user list, sendmail can reject things really quickly before even hitting mimedefang if you set up a virtuser table with a default reject and mappings for all addresses it should accept: @domain.com error:nouser No such user here validna...@domain.com validna...@delivery.address etc. If this is a "roll your own" situation, then I have a question regarding multiple-addressee emails. I plan to use the stream_by_domain option. At what point can I look at the email after it has been split into individual emails in order to do the database comparison? I'm not sure it even hits filter_recipient in this scenario unless it has a valid user name. I once made the mistake of running qmail for a domain and it's habit of accepting everything and later generating bounces seems to have gotten a whole dictionary attack onto some validated mail list that must be circulated or sold among spammers. I don't use that name any more but for years I was rejecting about 50k messages a day for it. I suppose that's not even a high volume any more... -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Re: On pinheaded ISP's (sort of OT)
[EMAIL PROTECTED] wrote: Les wrote on 01/31/2007 03:52:58 PM: Is 'your' queue better than everyone else's? Why not do a 4xx tmpfail if your address check temporarily fails? Any real MTA should be prepared to queue and retry. Why bother even having a backup MX if all it will do is return a 4xx? Why not let the sending server just fail to connect you your server and it will retry just as long before failing. You might want a backup MX or multiples that can run concurrently in case one of them has problems and the other(s) can provide equivalent relay service. However, this situation involves the primary delivery server or the authentication mechanism used to test for valid users. You can't deliver in any case. What's the point of accepting it then? My point of view may be skewed by getting about 50,000 dictionary attack attempts daily for the last few years, but accepting mail without knowing the address is valid is not healthy. You are just asking to overwhelm your own outbound queue with NDN's. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Re: On pinheaded ISP's (sort of OT)
Kevin A. McGrail wrote: If you can't reject during the initial SMTP phase, then your NDR's of spam, with their possible forged envelope addresses, will also be spam. So, if you can't drop at the initial conversation, or it is relayed from a backup MX, it is your message, and your problem. Just don't generate NDR's. If you can't return at SMTP, you will need to drop it. We'll politely disagree because I am doing my best to reject mail including having backup servers query primary servers for valid email addresses but when the primary server is down, we MUST queue mail up on our servers. If people choose to view that as us being the source of SPAM, then they are negating the entire point of having backup MX's for when stuff hits the fan. Is 'your' queue better than everyone else's? Why not do a 4xx tmpfail if your address check temporarily fails? Any real MTA should be prepared to queue and retry. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Re: compare mimedefang to mailscanner
John Rudd wrote: Accepting a message that your own scanners say contains spam/virus/bad-content, and then crafting a bounce message for it instead of delivering it, is a bad practice and should never be done. Dropping valid messages without notifying the sender is an even worse practice. "Bad content" is a fairly arbitrary concept. Can you honestly claim that you are anywhere near 100% correct in your determination of that?As an approximation I bump up the spamassassin scores on certain content to extremely high values and have MimeDefang reject with a message like "message screened for content, please rephrase". In at least some cases, that has found its way back to the sender as intended. 2) Don't accept it. Reject it. Give an SMTP 4xx or 5xx result, with a reason for why you didn't accept it. Let the submitting (SMTP client) host figure out what to do with it from there. Most likely it's a spam/virus bot, and the problem is resolved. MimeDefang can do this; I don't think Mailscanner can. You'll notice that neither of these is "bounce it". In a practical sense, it is. If the other end of the SMTP conversation is an RFC-conforming server, your 5xx rejection forces it to construct a bounce. If it is a virus, it will probably drop on the floor. The majority of my inbound mail is to unknown users. When I used a mailer that accepted, then bounced it would fill my outbound queue to the point that normal outbound mail was often delayed. Does mailscanner on a relay machine have a way to check valid users on the destination host before accepting? That's not mailscanner's job. That's the MTA's job. Which is why the scanner should run as a milter so it can inform the MTA what to do at the appropriate time. 1. The MTA says "yes that's a valid recipient" or "no, that's not a valid recipient", and accepts or doesn't accept the message accordingly. I run MimeDefang on a relay machine that has no concept of 'valid recipients'. So, the check you're talking about is done by the MTA in step one. It can do this with any number of possibilities (alias file, milter-ahead, mimedefang's recipient verification, an LDAP lookup, etc.). Mailscanner doesn't do that job for you. So, in my situation, MimeDefang is a win with it's md_check_against_smtp_server() function, along with its ability to reject with a reason in a way that at least sometimes does the right thing. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Re: compare mimedefang to mailscanner
Scott Silva wrote: That is why you never bounce. Reject, good -- bounce, bad! Umm, not if you are expecting the mail system to work... Mailscanner doesn't bounce spam by default. It hasn't for close to two years. But the option is still there, and is discouraged in the docs, in the comments of the config file, and is very discouraged on the lists. It comes down to two things. If you are required by law to archive "all" communications to or from your company, or like some countries cannot reject e-mail without a human being reviewing it, use mailscanner. If you can reject anything you please, and your users won't ask you for it later, use mimedefang. The only bounce messages I generate are for unknown users, The majority of my inbound mail is to unknown users. When I used a mailer that accepted, then bounced it would fill my outbound queue to the point that normal outbound mail was often delayed. Does mailscanner on a relay machine have a way to check valid users on the destination host before accepting? -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Re: compare mimedefang to mailscanner
Scott Silva wrote: I wanted to do a trial of f-prot. Just installed the rpm for f-prot, added its name to the config file, and now my system is scanning with 4 virus scanners. Took 5 minutes of my valuable time. It took several hours getting mimedefang going on just the smtp checks. I think what you are comparing is whether the example configs you could find were close enough to what you needed to cut and paste rather than actual complexity or efficiency -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Overcoming RPM stupidity
Michael Lang wrote:
%config(noreplace) /etc/mail/mimedefang-filter
%config(noreplace) /etc/mail/sa-mimedefang.cf
%config(noreplace) /etc/mail/sa-mimedefang.cf.example
%config(noreplace) /etc/sysconfig/%{name}
for my side i only modifyed less as possible in the original files and added a
require('myfilter.pl') the mimedefang-filter file. I overwrite there the
functions
i need or add additional ones ...
The RedHat way of thinking would probably put the user-configurable
piece in something like /etc/sysconfig/mimedefang-filter.pl and have
the base system version include that. Then at some unspecified time
in the future, a GUI tool might appear to help edit that file.
--
Les Mikesell
[EMAIL PROTECTED]
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] When to do Virus checks
On Thu, 2006-11-30 at 10:09 -0500, Joseph Brennan wrote: > > I think it is worth the extra CPU time to stop a virus at the earliest > > time possible. This makes it less dangerous, since the virus does not > > pass all the components of your emailscanning system. > > > I think you don't need a virus check at all, if you reject executable > file attachments. That's what a few years of experience tells me. What do you do with zip and other archive types that are popular virus containers? -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Reading/writing XML config files
On Sun, 2006-11-05 at 15:15, Philip Prindeville wrote: > > > >Why do you want to use XML? IMO, it's a solution looking for a problem. > > > Anyone else have anything to add to this? There are 2 advantages of xml. One is that you can use a generic parser even in languages that are strongly typed - this isn't all that important for perl. The other is that you can run a parser independently of the program to tell you if you have a syntax error, and some editors know automatically. This is a nice touch compared to the usual text config file and matching program that just refuses to start or crashes if you make a syntax error and have no way to check other than attempting to restart. And then you are down until you figure out what you did wrong. There are other ways to accomplish this, like webmin forms that must be kept in sync with the program itself or adding a 'test' option to the program that can be used before a restart, but xml lets you do it generically with the permitted types and value ranges specified in a schema. After you've learned to be very careful yourself you might forget about this problem. If you need a reminder, have someone else edit your critical program config files with a free form text editor... -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.58-BETA-1 is available
On Fri, 2006-10-27 at 10:43 -0400, Kevin A. McGrail wrote: > > > > Well, system administrators generally have a good reason for setting > > the maximum message size, and for RFC authors to attempt to subvert that > > is just plain wrong. > > Yes, but this was also written during the days of open relay and expected > multi-hop mail delivery. What the end-points enforced and what the > in-betweens decided were different. And if anyone is old enough to remember when it was difficult for anyone but a university to get an internet connection and uunet dialups were the way the rest of us had to work, there were ftp<->email gateways that were very useful for obtaining the latest copy of gcc and the like, and this couldn't possibly have worked without splitting the delivery across many messages. Times may change, but protocols don't - that's the point of having them... -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Potential for Business mail servers tonot havereverse DNS
On Sat, 2006-09-23 at 23:58, John Rudd wrote: > > > > A SHOULD is _never_ a requirement. > The section of RFC 1912 that I quoted directly contradicts you. It > lists a should, and outlines that the consequence for deviating from the > should may be denial of service. Therefore, it specifically states that > a should _may_be_ a requirement for service. Period. It is saying that there are circumstances other than RFC requirement compliance that can cause interoperability problems - like sites that add their own arbitrary requirements. That's just a realistic observation. You can't use that to say any RFC justifies these additional requirements even though the SHOULDs give best practices to work around them. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Potential for Business mail servers tonot havereverse DNS
On Sat, 2006-09-23 at 00:30, John Rudd wrote: > > > > If a SHOULD could be interpreted as a requirement, there > > wouldn't be any MUST's. > > > > There is absolutely no logic to your statement. > > > A MUST is _always_ a requirement. Even if a SHOULD is sometimes treated > as a requirement for service (as that RFC clearly states) it does not > displace the need for MUSTS, because a SHOULD is _not_ _always_ a > requirement for service. A SHOULD is _never_ a requirement. That is why there is a MUST. SHOULD's describe best practices, but by definition not strict requirments for interoperation. > And, there is nothing in the definition of the RFC use of the term > "SHOULD" which says you MUST NOT treat a SHOULD as a requirement for > service. You are, of course free to make any arbitrary choices about what you want to accept for your own site or domain. You can't however use an RFC SHOULD to justify it. SHOULD has a specific meaning, and it is not a strict requirement. > The most you can say is that making a SHOULD a requirement for > service is as cautionary to those who choose deny service on a SHOULD as > it is cautionary to those who would choose to not adhere to the SHOULD. No, you can say that is a misinterpretation. > In this specific case, the SHOULD outlines the consequence of not > adhering to the SHOULD. The purpose of a SHOULD is to allow deviation > but to caution those who would do so. By making it a requirement for > service, the implementers of that policy are applying those > consequences. They are not abusing the purpose of a SHOULD, confusing > it with a MUST, nor obsoleting the concept of a MUST. To suggest so is > nonsense. You are free to do whatever arbitrary things you want, but that's not what the word means and you can't claim RFC compliance as a reason for not interoperating in that circumstance. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Potential for Business mail servers tonot havereverse DNS
On Fri, 2006-09-22 at 20:32, John Rudd wrote: > Kevin A. McGrail wrote: > > > >> By "strict interpretation", I mean "enforce all of these as MUST > >> directives, instead of mere SHOULD directives/suggestions". > > > > I disagree with this statement but would like to have you review the > > code I'm about to post. RFC's use MUST/SHOULD on purpose and you must > > not reinterpet the should's as must's just because you like it better ;-) > > > Actually, given what SHOULD means (that those who fail to obey them > should fully consider the consequences of that action), and the text of > the RFC that I quoted (which warns that failure to comply could result > in service rejections), it's perfectly reasonable for a site to make > those recommendations into requirements for service (which is all I was > indicating). If a SHOULD could be interpreted as a requirement, there wouldn't be any MUST's. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Rejecting forged senders - comments?
On Wed, 2006-09-20 at 11:12 -0400, Kris Deugau wrote: > > In the end, I just do what I think is right, carefully reading the RFCs > > and my logfiles, but taking neither as gospel. > > Indeed. Local policy trumps anything else. > > If I decide, for whatever reason, to only accept mail from systems whose > IP contains a 3, that's my right as sysadmin. I wouldn't do something > like this on a business system, or ISP mail system, but for a private > server I'm free to accept or reject whatever traffic I like based on > whatever criteria I like. Of course you can do that, but it would be in bad taste to try to claim you were following internet standards or RFC's while doing it. And I'd say it would be pretty dicey to ask anyone about interoperability problems while choosing not to follow standards yourself - that is, everyone is equally free to reject your messages. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MD + Virtualization + Sizing
On Thu, 2006-08-03 at 08:31 -0500, Kayne Kruse wrote: > I just wondered if anyone here has any success stories running MD under > Xen or what not and what are the specs of that said machine? I'm not sure anyone considers Xen production-ready. The free version of VMware Server should sure to work, although probably with slightly more overhead than Xen. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: Secondary MX (was Re: [Mimedefang] What is the order of things thatoccur)
On Wed, 2006-07-12 at 10:39 -0400, Steve Campbell wrote: > In my case, the secondary MX is acting as a second gateway to my primary > MX+mailstore. The primary is highly available. But because it is a published > MX, it attracks spam. The "designed" purpose of md_check_against_smtp_server > is, in some ways, being used correctly here, as it does what it should do > when you consider it is running on a gateway. It's the design of my mail > system that is not being used properly. And the distributed user base would > fix that. Unfortunately, the 'suits' won't let me fix that for now. (Maybe > I'll just do it behind their backs) Why don't you move _both_ MX receivers to different machines, leaving your 'highly available' delivery server to serve real users while the spam fighting happens elsewhere? Then the check_against_smtp_server will work against the user base as it should and if one or the other of the MX gateways has a problem the failover will take care of it. If you are currently having enough trouble with the primary server to have noticed it, a plan with a good chance of fixing the problem should justify the extra box to the suits. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] filter_recipient
On Wed, 2006-07-05 at 19:35 +0200, Harry Otten wrote: > I have a mail server which runs some primary domains and some secondary > domains. > When mail comes in for which he is the secondary mail server he should > tempfail if and only if the primary server is still running. Is this also an outbound relay for any of the primary domains? If so, what happens when an internal user sends to an address at a secondary domain? > Nagios checks the primary server and puts the state in a database. > I currently made the script using the filter_end with @recipients and > accessing that database. Works nice, but I want to reject the messages > before the data block to safe bandwidth. > > To do so I must use the filter_recipient routine. > The filter_recipient is called after every RCPT TO. > > So I need to keep track of my state. Did I see a valid e-mail address? Than > the mail may pass, whatever other recipients there may be. If no valid > e-mail address appeared the e-mail should be rejected. But how do I know if > I'm called for the last recipient? > > That's my problem. > > When all the recipients are done the sending mail server issues the DATA > instruction. At this point I want to do filtering. > Instead of end your email with a dot we might temp fail. I thought if you failed all the recipients either the sender would quit on its own or DATA would be rejected. Are you sure this doesn't already happen? -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Re: Simplified single purpose mimedefang-filter
On Sat, 2006-06-24 at 10:43, John Rudd wrote: > Sbcglobal is, IIRC, one of the ISPs which makes you sign something > specific in order to keep your service from preventing direct outbound > access on port 25. (ie. they as an ISP don't let their clients make > direct connections to port 25 other than to their own mail servers; but > they do have a web page you can go to to request an exception). If this is a personal account, the quick fix might be to get a gmail account and relay through their authenticated smtps on port 465 or 587. You have to poke around in the POP setup to see how to do this, but you don't have to use the gmail web interface to send. -- Les Mikesell [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
