Re: Reputation based filtering...
On Tue, 2009-06-09 at 11:20 +0530, Anant Athavale wrote: > Dear List: > > We have got one Ironport appliance for evaluation. It does reputation > based filtering and drops lots of mails. But, we are still running > Postfix with SpamAssassin for Anti-SPAM. > > Can Postfix can be integrated with something for reputation based > filtering? > > > Anant Athavale > Not sure regarding the Ironport, but I imagine it is just the same as the Barracuda. The 'Reputation' is just an in-house rbl list and Yes, Postfix does these very well indeed. Here I am making use of a few; smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org reject_rbl_client pbl.spamhaus.org reject_rbl_client dnsbl.sorbs.net reject_rbl_client b.barracudacentral.org Apart from a pretty GUI, you can achieve virtually all of what an Ironport or Barracuda does with Open Source *free* software. That's all those 'appliances' are. Open Source cobbled together and sold to you. My money would say - don't waste your cash on the Ironport (and certainly don't spend a cent on a Barracuda).
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 12:51 +0200, Magnus Bäck wrote: > On Fri, June 12, 2009 12:12 pm, Steve said: > > > Is this right? > > > > "You cannot whitelist a sender or client in an access list to bypass > > header or body checks. Header and body checks take place whether you > > explicitly "OK" a client or sender, in access lists, or not." > > Yes, that's correct. > Is there any kind of feature request to change this behaviour? Such as allowing a map list of client ip's or ranges that can 'hop over' the header/body checks all together? If I forward a spam mail to an abuse department quoting full headers (even in the body of the mail) they seem to 'catch' on header rules. I'm not sure if this is a bug/'feature' - but to have to keep commenting out certain rules to get them sent is a minor hassle.
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 14:36 +0100, Mark Goodge wrote: > Steve wrote: > > On Fri, 2009-06-12 at 08:17 -0400, Wietse Venema wrote: > >> Mark Goodge: > >>> Ralf Hildebrandt wrote: > * Steve : > > Is this right? > Yes > > "You cannot whitelist a sender or client in an access list to bypass > > header or body checks. Header and body checks take place whether you > > explicitly "OK" a client or sender, in access lists, or not." > > > > I'm gob smacked if it is? > Why? > >>> Because it rather misses the point of whitelisting. > >> To forward spam reports through Postfix, the recommended solution > >> is to BASE64 encode the "offending" content. > >> > >> See http://www.postfix.org/BUILTIN_FILTER_README.html for points > >> discussed in this thread and more. > >> > >>Wietse > > Always a clever answer for a bug - nice one :-) wanker. > > I wouldn't call it a bug, since it's a feature that works as designed. > It is, however, a design choice that makes the feature less useful than > it otherwise could have been. But the point here is that content > inspection isn't a core part of the job of an MTA anyway, so if the > rather simplistic version built in to Postfix isn't sufficient then > you're no worse off than if it didn't have the facility to begin with. > The fact that it does it at all is a bonus that may be useful in some > cases where whitelisting isn't necessary. > > Actually, if you wanted to do it all with Postfix then I think one > solution could be to use multiple SMTP services. Have all inbound mail > go to the first service, where mail from whitelisted sources is handled, > then all remaining mail is delivered to the second service which does > header checks before processing the mail. But there may be other gotchas > with this that I haven't thought of. > > Mark It's a bug. Read the original question carefully. If I'm pasting the original headers into the BODY of a fresh mail, and the header filters are *blocking* it - is that intended behaviour? Answer (hopefully) 'No'. It's not worth filing a bug report because all that Wietse (and Ralph) want to do is argue with people all the time. If it's broke, bloody fix it. It's really THAT simple :-)
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 15:47 +0200, Ralf Hildebrandt wrote: > * Mark Goodge : > > > I wouldn't call it a bug, since it's a feature that works as designed. > > It is, however, a design choice that makes the feature less useful than > > it otherwise could have been. But the point here is that content > > inspection isn't a core part of the job of an MTA anyway, so if the > > rather simplistic version built in to Postfix isn't sufficient then > > you're no worse off than if it didn't have the facility to begin with. > > The fact that it does it at all is a bonus that may be useful in some > > cases where whitelisting isn't necessary. > > I only use it for stuff I absolutely don't want to see. Everything > else gets handled by amavisd-new Which is flaky. The fix is to make the content scanner in Postfix work as it should - or do we keep making excuses for it so we don't upset *you know who*
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 15:54 +0200, Ralf Hildebrandt wrote: > * EASY steve.h...@digitalcertainty.co.uk : > > > > I only use it for stuff I absolutely don't want to see. Everything > > > else gets handled by amavisd-new > > > > Which is flaky. > > Not here. And the tens of thousands of Barracuda owners out there with a whole service dedicated to bouncing amavis-new because it so flaky pale into insignificance when placed against your total mastery of the world ;-) > > > The fix is to make the content scanner in Postfix work as it should - > > or do we keep making excuses for it so we don't upset *you know who* > > I read the other mail about pasting the headers into the body and then > the header_checks trigger again. Can you show a minimal example for > that (with log lines)? > Why - like it will ever get fixed! Nah. It's easy enough to recreate if you really gave a damn. Don't be so lazy.
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 16:40 +0200, Ralf Hildebrandt wrote: > * Ralf Hildebrandt : > > * Steve : > > > > > /^Received: from.*(cmodem|dhcp|adsl|broadband|dynamic)/ REJECT dynamic > > > host in headers > > > > OK > > > > > In the logs; tripped on the header filter; > > > Jun 12 11:01:58 mail4 postfix/cleanup[1419]: B9F16AC09D: reject: header > > > Received: from [192.168.1.xx] (xx [192.168.1.xx])??by mail4.xx.co.uk > > > (xx) with ESMTPA id B9F16AC09D??for ; Fri, 12 Jun > > > 2009 11:01:58 +0100 (BST) from mail4[192.168.1.xx]; > > > from= to= proto=ESMTP > > > helo=<[192.168.1.xx]>: 5.7.1 dynamic host in headers > > > > The regular expression is too broad, since it also matches the "for > > " > > portion in the headers! > > Since the headers look like: > > Received: from [192.168.1.xx] (xx [192.168.1.xx]) NEWLINE > by mail4.xx.co.uk (xx) with ESMTPA id B9F16AC09D NEWLINE > for ... > > You COULD solve this using: > > /^Received: from .*(cmodem|dhcp|adsl|broadband|dynamic).*by / REJECT dynamic > host in headers > > It's worth a try. > Indeed, but it's *not* in the header section of the email, is it! It has been pasted into the *BODY* of an email.
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 16:50 +0200, Ralf Hildebrandt wrote: > * EASY steve.h...@digitalcertainty.co.uk : > > > > for ... > > > > > > You COULD solve this using: > > > > > > /^Received: from .*(cmodem|dhcp|adsl|broadband|dynamic).*by / REJECT > > > dynamic host in headers > > > > > > It's worth a try. > > > > > Indeed, but it's *not* in the header section of the email, is it! It has > > been pasted into the *BODY* of an email. > > Try forwarding it someplace else, instead of ab...@btbroadband.com > > Whenever you're forwarding it to a recipient that matches > (cmodem|dhcp|adsl|broadband|dynamic) -- in this case "btbroadband.com" > matches "broadband" you'll be seeing this, since you own Received headers > will match the header_checks regexp. > > You COULD strip your own internal Received: headers to avoid this. But > that's solving the wrong problem. > Yep, I had already done that. I tried the same thing to ab...@bt.com and got the same result. Of course the *easy* fix would be for me to allowed to *whitelist* senders so they were not subjected to header and body checks.
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 16:56 +0200, Ralf Hildebrandt wrote: > * EASY steve.h...@digitalcertainty.co.uk : > > > Yep, I had already done that. I tried the same thing to ab...@bt.com and > > got the same result. > > Log entry for exactly that case? > reads 6 minutes later but was sent to 'ab...@bt.com' rather than 'ab...@btbroadband.com' - other than that, it's all identical.
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 12:36 -0400, Wietse Venema wrote: > Steve: > > On Fri, 2009-06-12 at 11:07 -0400, Wietse Venema wrote: > > > If there is a reproducible example where header_checks triggers on > > > body content, then I will fix it. > > > > > > All I ask for is that conditions be independently reproducible. > > > > > > Wietse > > In the meantime - how do I white-list this? > > Currently, the option is: Does that mean you will be introducing white listing for this in a future release?
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 14:09 -0400, Wietse Venema wrote: > EASY steve.h...@digitalcertainty.co.uk: > > On Fri, 2009-06-12 at 12:36 -0400, Wietse Venema wrote: > > > Steve: > > > > On Fri, 2009-06-12 at 11:07 -0400, Wietse Venema wrote: > > > > > If there is a reproducible example where header_checks triggers on > > > > > body content, then I will fix it. > > > > > > > > > > All I ask for is that conditions be independently reproducible. > > > > > > > > > > Wietse > > > > In the meantime - how do I white-list this? > > > > > > Currently, the option is: > > Does that mean you will be introducing white listing for this in a > > future release? > > Currently, as in, what is available now. I am not good > at predicting the future. > > Wietse I know. If you were I would not be asking for basic features you never had the foresight to see would be requested for by end users ;-) I'll see if I can find a link for you do download a virtual crystal ball to help (blows dust off 5 inch floppy disc)
Re: Can't whitelist header / bodychecks
On Fri, 2009-06-12 at 14:52 -0400, Victor Duchovni wrote: > On Fri, Jun 12, 2009 at 07:40:27PM +0100, EASY > steve.h...@digitalcertainty.co.uk wrote: > > > > Currently, as in, what is available now. I am not good > > > at predicting the future. > > > > I know. If you were I would not be asking for basic features you never > > had the foresight to see would be requested for by end users ;-) > > Some "end users" put the wrong "end" of their torso to use when composing > feature requests. :-) The scheduler queue for feature requests is > top-down. > That's because some coders half do a tardy job and then use that wrong torso end to defend it.
Header Filter Time Range
Probably a stupid question, but in practical terms is it possible to set a header filter that will reject (or ideally defer) mail on time range? For example during the hours of 00:00 -> 07:00. I appreciate that the action will probably have to be 'reject' if it is possible at all. Has anyone tried/implemented this and what are the thoughts/comments on it. TIA.
Re: Header Filter Time Range
On Mon, 2009-06-15 at 01:58 -0600, LuKreme wrote: > On 15-Jun-2009, at 01:09, EASY steve.h...@digitalcertainty.co.uk wrote: > > Probably a stupid question, but in practical terms is it possible to > > set > > a header filter that will reject (or ideally defer) mail on time > > range? > > For example during the hours of 00:00 -> 07:00. > > Erm.. well, yes, you COULD do that, but why? > > $ cat header_checks.pcre > # Emails with erroneous dates (or dates far in the past) will appear > at the top or bottom of your mail client. > /^Date:.* 19[0-9][0-9]/ REJECT Your email has a date from the past. > Fix your system clock and try again. > /^Date:.* 200[0-8]/ REJECT Your email has a date from the past. > Fix your system clock and try again. > /^Date:.* 20[1-9][0-9]/ REJECT Your email has a date from the > future. Fix your system clock and try again. > > That should give you the idea... Thanks - I'll play with this > > > I appreciate that the action will probably have to be 'reject' if it > > is > > possible at all. Has anyone tried/implemented this and what are the > > thoughts/comments on it. > > Well, it seems like a spectacularly bad idea to me... > Normally I would agree, but in an experimental environment it's worth playing with to evaluate. Look at it like this, if you go to the supermarket when it is closed for business you don't expect to be able to get in :-)
Re: blacklists
On Thu, 2009-06-18 at 15:04 +0200, polloxx wrote: > Dear, > > we use blacklists as a first defense against spammers. We have hese > lists at our postfix server: > > reject_rbl_client pbl.spamhaus.org, > reject_rbl_client list.dsbl.org, > reject_rbl_client bl.spamcop.net, > reject_rbl_client safe.dnsbl.sorbs.net, > reject_rbl_client cbl.abuseat.org, > > Since the end of May blacklisting is performing worse. Is there an > explanation for this? > Are there other good blacklists you can recommend? > > thx. I note that this one; no-more-funn.moensted.dk Often has a good hit rate, but in production I can't speak for its latency.
Re: Defer All INET
On Thu, 2009-06-18 at 14:42 -0400, Victor Duchovni wrote: > On Thu, Jun 18, 2009 at 01:13:21PM -0500, Noel Jones wrote: > > >> # /etc/postfix/deferall.regexp > >> /^/ DEFER Please try again during business hours > > > > The sender may get a better error message if you change the above to > > /^/ DEFER 4.3.2 Please try again during business hours > > > > The 4.3.2 suggests your system is down for maintenance and may influence > > the error the end user sees if they have an MTA that mangles error codes. > > Yes. This said, the OP is setting a poor example. > I would advise him > and others to consider other solutions to whatever problem motivates > this policy. The Internet is international and multi time-zone. What > is business hours for one person is night-time for another, and forcing > legitimate mail to queue for hours is counter-productive. But it still does *not* mean there is anyone in the office to answer any legitimate mail - come back later when we are open. It's simple enough. The world and time zones are the same as they always have been. If someone in Australia calls a business number in the UK during the middle of the night will they get to speak to a person? No. Has this changed since the internet? No. If they send a fax will it get answered? No. What makes email any different? That's not a bad example at all, it's a sensible policy from an operational and possibly even an environmental and security perspective. Imagine building the intelligence into simply proxy service running on the firewall/gateway to defer 25 request outside of office hours allowing the mail server to be shut down. I can't see any disadvantages other than upsetting a few unreasonable people who think they should be able to contact us when we are closed. We can argue the pro's and con's but I'm about to close for business so I won't be able to respond until the morning. Good night. Man, this even improves my work/life balance as I know there are *no incoming emails* to check! Brilliant! >
Re: Cyrus-sasl + postfix + postgresql problem.
On Sun, 2009-06-21 at 10:35 +0200, Rafał Radecki wrote:
> Hi all. I'm currently installing an smtp server on CentOS 5.3. Part of
> it is to use PostgreSQL backend to store virtual
> users/domains/aliases/passwords and of course to use it for SASL
> authentication. My /usr/lib/sasl2/smtpd.conf file:
>
> pwdcheck_method: auxprop
> sql_engine: pgsql
> sql_user: postfix
> sql_passwd: some_password
> sql_hostnames: localhost
> sql_database: postfix
> sql_select: SELECT password FROM mailbox WHERE username='%...@%r'
> mech_list: login plain
> log_level: 4
>
> My /etc/postfix/main.cf:
>
> smtpd_sasl_auth_enable = yes
> broken_sasl_auth_clients = yes
> smtpd_sasl_local_domain = $mydomain
> smtpd_sasl_security_options = noanonymous
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, \
> reject_unauth_destination
>
> virtual_alias_maps = pgsql:/etc/postfix/pgsql_virtual_alias_maps.cf
> virtual_alias_domains = $virtual_alias_maps
> virtual_uid_maps = static:1004
> virtual_gid_maps = static:1004
> virtual_mailbox_base = /var/spool/mail/virtual
> virtual_mailbox_domains =
> pgsql:/etc/postfix/pgsql_virtual_domains_maps.cf
> virtual_mailbox_maps =
> pgsql:/etc/postfix/pgsql_virtual_mailbox_maps.cf
> #virtual_mailbox_limit = 5120
> transport_maps = pgsql:/etc/postfix/pgsql_transport.cf
>
> I use that line to insert a record to the PostgreSQL base:
>
> postfix=>INSERT INTO mailbox(username, password, name, maildir)
> postfix->VALUES('r...@example.com','password','description','r...@example.com/');
>
> But when i try to send mail through my server i get the following
> errors in /var/log/maillog:
>
> warning: SASL authenticatin problem: unable to open db etc/sasldb2: no
> such file or directory
What mechanism are you using for the SASL? Unless I'm getting confused
here you need something like the Cyrus/Dovecot SASL 'guts' to make it
work.
>
> I'm quite confused because i thought that all authenticaton data
> should be taken from mentioned PostgreSQL database.
But it needs the interface. I'm no expert but I think you've got
something missing here (or mis-configured) with whatever is offering the
'SASL' service to Postfix.
>
> Any help will be very kindly appreciated.
>
> With regards,
> R.
Please treat my answer with much caution. I know only a tiny fraction
about SASL compared to the guru's that post here. I've only answered
because it is Sunday and it may be as simple as you've missed a chunk in
your setup'. Hopefully someone else with better experience will give you
better advice.
>
>
>
>
>
>
Re: Cyrus-sasl + postfix + postgresql problem.
Strike that, I've just noticed you crossposted to; cyrus-s...@lists.andrew.cmu.edu, Please ignore my stupid answer.
Re: Cyrus-sasl + postfix + postgresql problem.
On Sun, 2009-06-21 at 15:16 +0100, Steve wrote: > On Sun, 2009-06-21 at 15:58 +0200, Rafał Radecki wrote: > > I corrected my mistake but it doesn't help. Any other ideas? > What are the logs saying? > OFF LIST RESPONSE RECEIVED; >/var/log/maillog: >Jun 21 17:54:00 localhost postfix/smtpd[3091]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory >Jun 21 17:54:00 localhost last message repeated 3 times >Jun 21 17:54:00 localhost postfix/smtpd[3091]: warning: localhost.localdomain[127.0.0.1]: SASL LOGIN authentication failed: authentication failure >Jun 21 17:55:04 localhost postfix/smtpd[3091]: lost connection after AUTH from localhost.localdomain[127.0.0.1] To my eyes: Berkeley db /etc/sasldb2 != PostgreSQL back end
Re: Reporting Connection Attempts back to originators ISP
On Mon, 2009-06-22 at 15:30 +1200, Justin C. Le Grice wrote: > I'm sorry if this has already been done to death but I have searched > high and low and have found scant discussion of this. > > I have been running Postfix for three weeks now and have reduced spam to > just one or two messages getting through a day. > I have implemented recommended anti spam settings from a number of sites > which include HELO, RBL and DNS checks. > > I am running Postfix 2.5.5 with Amavis-New on Ubuntu Server 9.04 > My main.cf contains the following; > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_client_access hash:/etc/postfix/mywhitelist, > reject_rbl_client bl.spamcop.net, > reject_rbl_client dnsbl-1.uceprotect.net, > reject_rbl_client dnsbl-2.uceprotect.net, > reject_rbl_client sbl-xbl.spamhaus.org, > reject_rbl_client dnsbl.njabl.org, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_unauth_destination, > permit > > smtpd_data_restrictions = > reject_unauth_pipelining, > permit > > # Strange Syntax / Strict syntax > smtpd_helo_required = yes > strict_rfc821_envelopes = yes > > #No VRFY command > disable_vrfy_command = yes > > content_filter = smtp-amavis:[127.0.0.1]:10024 > receive_override_options = no_address_mappings > > Note: I have the RBL's first to see how effective they are. I'll > probably drop them down before the permit line at some stage. > > While I am more than happy with the reduction in spam I would like to > use my log files to be proactive in letting ISPs know that they have > bots in their networks. I am presuming that most of the attempts to > connect are from bot infected home computers, judging from the FQDN that > is used in the connection. > > I have been trying to find something that will do the following. > > Analyse my mail.log file looking for occurances of rejected attempts to > connect to my mail server. > At some user defined threshold it would then do a whois query looking > for an abuse@<> email address. > It would the send a nicely worded message detailing the attempt to use > my mail server for spamming and request that the connection be > terminated until the user fixes their compromised machine. > > Am I just being wishful here?? > > Cheers > > Justin Any kind of 'automated' message system is about as welcome as a needle in a Durex factory in spam land so my own advice would be don't do it. Whilst it's not 'backscatter' it has potential for mishaps. There are plenty of stats programs out there that require differing levels of setting up. I'm told awstats is rather nice but I've never tried it with Postfix. Failing that Perl is your friend and getting a little script working looking at failed connection attempts and tallying the responsible IP(s) is relatively easy going. I'm fiddling with one myself at the moment and when I'm done with it I'm happy to share it.
Re: Postifix-v-Spamassassin BLOCK SMTP
Joey wrote:
> >
> > Actually, I use a header_checks rule:
> >
> > /X-Spam-Level: \*{5,}/ REJECT
I wrote;
> I looked at this myself and asked 'hang on, what if I put a header
> filter in for X-Spam-Level'. I assumed (and that is all it was) that it
> was not fed into the content filter until *after* Postfix had accepted
> the whole message. ? ? If that is the case and it tried to bounce this
> I'm not entirely sure of the carnage this would create. I'll have to
> play with it as this looks like to easy and obvious to miss!
And yep, having tested it - that does not work as intended;
250 2.0.0 Ok: queued as C4E83AC0C6
So it takes it and then has to bounce it :-(
It then tries to 'bounce' and could end up joe-jobbing some innocent
person. I just did.
Re: Postifix-v-Spamassassin BLOCK SMTP
On Tue, 2009-06-23 at 15:52 +0200, Ralf Hildebrandt wrote: > * The Doctor : > > > I am contemplating howto use spamassassin effectively with postfix. > > Usually we use amavisd-new Depends how often you want to keep restarting it. My time at Barracuda taught me to steer clear of Amavis. 'Captain Crash' was its nickname. I appreciate that you, Ralf, love it and say it scales well. I respect that but it's not my experience. In the Barracuda boxes running it (handling large volumes into the millions of messages a day area) it was one of three common points of failure. I'm happy to steer clear of it but It's good that it works for you. Having done a little reading I was not keen on the spamd option. I've opted to play with this following a list suggestion; SpamAssassin Milter Plugin (http://savannah.nongnu.org/projects/spamass-milt/)
Re: Postifix-v-Spamassassin BLOCK SMTP
On Tue, 2009-06-23 at 11:08 -0500, Noel Jones wrote: > EASY steve.h...@digitalcertainty.co.uk wrote: > > On Tue, 2009-06-23 at 15:52 +0200, Ralf Hildebrandt wrote: > >> * The Doctor : > >> > >>> I am contemplating howto use spamassassin effectively with postfix. > >> Usually we use amavisd-new > > > > Depends how often you want to keep restarting it. My time at Barracuda > > taught me to steer clear of Amavis. 'Captain Crash' was its nickname. > > > > I appreciate that you, Ralf, love it and say it scales well. I respect > > that but it's not my experience. In the Barracuda boxes running it > > (handling large volumes into the millions of messages a day area) it was > > one of three common points of failure. I'm happy to steer clear of it > > but It's good that it works for you. > > The one time I tried using a hammer, I kept getting injured. > I'll never use another hammer. No, I never asked anyone for > advice, the instructions seemed simple enough. I'll bet all > those other people using hammers just ignore the pain. > > Had I have been a Barracuda developer I would have asked for advice. I was not. Me just a low grade tech support droid having to restart amavis day in, day out in many of those hundreds of thousands of units they have sold. I guess those that 'stole' what is the Barracuda spam (and virus) firewall from Open Source did ask many questions. You may have even answered some. What is for sure is they have real life demonstrable use of amavis-new in high volume environments and from what I've seen of it - it sucks. Let me know if you get the guts to try a hammer again.
Re: Postifix-v-Spamassassin BLOCK SMTP
On Tue, 2009-06-23 at 18:59 +0200, Benny Pedersen wrote:
> On Tue, June 23, 2009 18:46, Steve wrote:
> > I am assured that it is amavis-new :-) However, I've also been told the
> > lottery numbers over and over and I've not won a penny.
>
> well you need to play if you want to win, admins like me get fingers very
> dirthy one or more times, but for me its the road to be a better nerd :)
>
It could very easily be the way that Barracuda configure it. They are
not known for their programming expertise. They have to share Micky
Mouse with Disney Land for half the year
I can confirm it's Amavis-new if the start script on the model I have in
front of me is to be believed...
!/bin/sh
#
# amavisd This script controls the amavisd-new daemon.
# (to be used with version amavisd-new-20020630 or later)
#
# chkconfig: 2345 98 31
# description: amavisd is an interface between MTA and content checkers
# processname: amavisd
# pidfile: /var/spool/scan/amavisd.pid
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Source timezone info
. /home/emailswitch/code/firmware/current/etc/tz
# force perms on /mail/scan
/bin/chown -R scana.scana /mail/scan
# Make sure the stats.log file is in place and writable
touch /mail/log/stats.log
chmod 777 /mail/log/stats.log
# Empty the stats log file if it is larger than 20 MB
size=`du -m /mail/log/stats.log | cut -f1`
if [ $size -ge 20 ] ; then
`cat /dev/null > /mail/log/stats.log`;
fi
prog="/home/emailswitch/code/firmware/current/bin/amavisd"
prog_base="$(basename ${prog})"
prog_config_file="/home/emailswitch/code/firmware/current/etc/amavisd.conf"
# Source configuration.
[ -e /etc/sysconfig/${prog_base} ] && . /etc/sysconfig/${prog_base}
RETVAL=0
# See how we were called.
case "$1" in
start)
# Make sure amavisd is down
killall -9 amavisd
# Start intent server
/home/emailswitch/code/firmware/current/sbin/intentctl start
# Start up amavisd
echo "cleaning scan directory of amavis- files"
find /mail/scan -name "amavis-*" -prune -exec rm -fr {} \;
action $"Starting ${prog_base}:" ${prog} -c ${prog_config_file}
RETVAL=$?
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/${prog_base}
PLATFORM="1"
if [ -f "/etc/barracuda/platform" ]; then
PLATFORM=`/bin/cat /etc/barracuda/platform`
fi
if [ "$PLATFORM" != "1" ]; then
/usr/bin/killall lmtp
echo "sleep 10 && /usr/bin/killall -HUP master" | /bin/sh &
fi
;;
stop)
# Go ahead and shut-down amavisd now
action $"Shutting down ${prog_base}:" ${prog} -c ${prog_config_file}
stop
RETVAL=$?
if [ $RETVAL -eq 0 ] ; then
echo "${prog_base} stopped"
rm -f /var/lock/subsys/${prog_base}
fi
# Remove any "start" locks, in case we're unlucky with a race
# condition.
rmdir $start_lockdir >/dev/null 2>&1
# Shut down intent server
/home/emailswitch/code/firmware/current/sbin/intentctl stop
;;
# reload)
## Let reload do a quick stop/start w/o dealing with the mta
overhead
## this should only be used on systems which aren't very loaded
otherwise
## the mta will quit talking to amavisd
#
## Reload intent config
#/home/emailswitch/code/firmware/current/sbin/intentctl reload
#
#action $"Shutting down ${prog_base}:" ${prog} -c
${prog_config_file} stop
#action $"Starting ${prog_base}:" ${prog} -c ${prog_config_file}
#;;
status)
status ${prog_base}
RETVAL=$?
;;
reload|restart)
$0 stop
$0 start
RETVAL=$?
;;
*)
echo "Usage: $0 {start|stop|status|restart|reload}"
exit 1
esac
# Quit out with the last retrun value we had
exit $RETVAL
Re: Postifix-v-Spamassassin BLOCK SMTP
On Tue, 2009-06-23 at 11:50 -0500, Noel Jones wrote: > Sahil Tandon wrote: > > Noel are you suggesting something might not work for me because I don't > > know how to use it? Blasphemer! > > ;-) > Next I'll ask you about painting my bike shed... How dare you waste a shed on Bikes! I would fill it with servers. Actually Noel. Do you have space for 42U in there? I know a rbl that could use your help.
Re: Anvil Syntax THANKS
On Wed, 2009-06-24 at 11:07 +0200, Ralf Hildebrandt wrote: > * Steve : > > > smtpd_client_event_limit_exceptions = my_networks > > smtpd_client_event_limit_exceptions = $mynetworks > > > or > > > > smtpd_client_event_limit_exceptions = my_networks, 1.2.3.4, 5.6.7.8 > > smtpd_client_event_limit_exceptions = $mynetworks, 1.2.3.4, 5.6.7.8 > > > and that will be good? > > Yep > You could even do stuff like: > smtpd_client_event_limit_exceptions = !10.0.0.1, 10.0.0.0/8 I'm told it is bad netiquette to say 'thank you' on a mailing list - and I assume that is true here? But thank you Ralf for taking the time to help me fix my issue and further my understanding. It's all about the $ :-)
Re: Pre Queue Spam Assassin Advice
On Wed, 2009-06-24 at 13:32 -0400, Victor Duchovni wrote: > On Wed, Jun 24, 2009 at 05:49:45PM +0100, Steve wrote: > > > Hi List, > > > > I've been having some adventures with pre queue filtering with > > SpamAssassin. This has introduced me to 'milters' which look really > > interesting. > > > > I've been trying to set up suggested spamassassin milter > > (spamass-milter) but I'm find large gaps in my basic Linux > > understanding.I don't mind admitting that I'm stupid and need help at > > times. My question is more 'unix' than 'Postfix' but someone here will > > know. > > > > If I have a milter set up and it creates a 'unix socket' on start up, > > e.g. > > /home/mail/email/private/samilter > > > > then defining the milter in main.cf like this (bear in mind Postfix is > > running chrooted) > > smtpd_milters = unix:/private/samilte > > milter_default_action = tempfail > > "/private/samilte" != /home/mail/email/private/samiler > Postfix runs chrooted and the absolute would be incorrect. It's chrooted to /home/mail/email hence it is correct as far as I understand it.
Re: Pre Queue Spam Assassin Advice
On Wed, 2009-06-24 at 14:02 -0400, Victor Duchovni wrote: > On Wed, Jun 24, 2009 at 06:54:37PM +0100, Steve wrote: > > > > > > > milter_default_action = tempfail > > > > > > > > > > "/private/samilte" != /home/mail/email/private/samilter > > > > > > > > > Postfix runs chrooted and the absolute would be incorrect. It's chrooted > > > > to /home/mail/email hence it is correct as far as I understand it. > > > > > > Note, the difference is more than just the path prefix. > > > > > That was just a pasting typo. Apologies. It is correct on the box > > (samilter) > > It looks like some of your smtpd(8) master.cf entries are chrooted and > others are not. You should use the unchrooted pathname in both cases, > and make a symlink: > > /home/mail/email/home/mail/email -> / > > so that the same pathname works in both cases. > That sounds plausible enough to me. I'm sure I read that symlinks and chrooting was carnage - but I'm willing to give anything a go. It's not going to bring down the space station :-) My only confusion is where do I put the symlink. To make matters a struggle for me I'm dyslexic so please forgive me a little as I'm struggling to follow this: /home/mail/email/home/mail/email - I see the same things twice and this locks me up a bit. For my own clarity (I'll adapt this when I unscramble it) I guess it would be OK to make a symlink to the socket thus; LINK POINTS TO: /home/mail/email/private/samilter WHERE DO I 'PUT' LINK? Where does the link need to be -v- the duplication in the path is confusing me. ln -s /home/mail/email/private/samilter / # run from /home/mail/email ???
Re: Log Stats
On Fri, 2009-06-26 at 17:28 +0200, Jiří Hlinka wrote: > Hi, > beside pflogsumm there is postfix-logwatch and amavis-logwatch: > http://www.mikecappella.com/logwatch/ > > Jiri > > Steve napsal(a): > > Hi List, > > > > Before I make a feeble attempt to reinvent the wheel with a custom log > > parser, can anyone recommend a log file analyser which could output a > > single line summary of every connection be it allowed or blocked? > > Ideally I would like to be able to format the output for html. > > > > Really I'm asking for recommendations I guess, from experienced users > > here. > > > > Thank you and warm regards > > Steve > > > > > > > > > Hi Jiri - I'm looking at both suggestions from both responders. Thanks.
Re: Bounce / NDR messages - how to stop them
On Mon, 2009-06-29 at 08:20 -0400, Charles Marcus wrote: > On 6/29/2009, Steve (steve.h...@digitalcertainty.co.uk) wrote: > > I've read a few archive posts regarding the generation of bounce/ndr > > messages and I can understand some of the cutting remarks such as 'don't > > accept mail for invalid users in the first place'. > > Yep - but accepting for invalid users is different from your problem > described below of bouncing due to failing CONTENT inspection... > > > That aside, is it actually possible to stop the SENDING (or the > > generation) of NDR/Bounce messages. > > It might be possible to do this ONLY for messages that fail the content > inspection, but otherwise, postfix doesn't 'send' NDRs, it simply > rejects the message at smtp time - it is the ORIGINATING server (the one > that SENT the message) that generates the NDR. > > If your server is accepting then bouncing, something is broken... fix > the problem. > > I don't do it, but I think you can have a before queue content filter > using amavisd-new and spamassassin... > > > I have a couple of content milters / filters running that hold the mail > > during the data stage and inspect it. I appreciate that the RFC's say > > the decision needs to be made before the DATA section - but that is not > > always ideal. > > The rule is simple... if you accept the message, don't bounce it > afterwards, but if you must for some specific reason accept a message > and then reject it for whatever reason afterwards, the RFC requires a > bounce (I think). The best way to deal with this is if you accept the > message and then it fails some content inspection, just tag it and > deliver to a spam folder or something. > Appreciate that - but to do this defeats the object of rejecting mail at SMTP time (to avoid the bounce in the first place). What appears to happening is the spambot sending the mail does not hang around for the 250 OK at the end of the .. If it did, it would have been SMTP rejected. (no bounce ever needed). Sure - it's not RFC compliance to *not* bounce something you have accepted responsibility for - but Postfix had not taken responsibility. It never gave a 250 OK. I would never have given a 250 OK for the message concerned. I have some concern that clamsmtp may be 'misfiring' because the logs show (127.0.0.1[127.0.0.1]:10025) it being involved. However, I can recreate this if I telnet it and drop off without waiting for the OK after the data. Jun 29 08:54:27 mta1 postfix/smtp[14068]: 5B63AAC10C: to=, relay=127.0.0.1[127.0.0.1]:10025, delay=2, delays=1.2/0.01/0.06/0.76, dsn=5.7.1, status=bounced (host 127.0.0.1[127.0.0.1] said: 550 5.7.1 Blocked by Spamassassin (in reply to end of DATA command)) But as far as I can tell, it's not given a 250 OK anywhere so it should not have gone on to produce a bounce from the blocked message (which in turn was 550'd); Jun 29 08:54:27 mta1 postfix/bounce[14074]: 5B63AAC10C: sender non-delivery notification: 60FDDAC8C2 Jun 29 08:54:27 mta1 postfix/qmgr[13983]: 5B63AAC10C: removed Jun 29 08:54:27 mta1 postfix/qmgr[13983]: 60FDDAC8C2: from=<>, size=4371, nrcpt=1 (queue active) Jun 29 08:54:30 mta1 postfix/smtp[14076]: 60FDDAC8C2: to=, relay=coolest-gadgets.com[75.127.98.32]:25, delay=3.4, delays=0.01/0.01/3.3/0.15, dsn=5.0.0, status=bounced (host coolest-gadgets.com[75.127.98.32] said: 550 No Such User Here" (in reply to RCPT TO command))
Re: Bounce / NDR messages - how to stop them
On Mon, 2009-06-29 at 11:32 -0400, Wietse Venema wrote: > EASY steve.h...@digitalcertainty.co.uk: > > Appreciate that - but to do this defeats the object of rejecting mail at > > SMTP time (to avoid the bounce in the first place). What appears to > > happening is the spambot sending the mail does not hang around for the > > 250 OK at the end of the .. If it did, it would have been SMTP > > rejected. (no bounce ever needed). > > As delivered, Postfix does not send a bounce email message when it > can't give the bad news directly to the remote SMTP client. > > If your Postfix does, then you have a non-obvious configuration, > and sharing that may help to un-confuse the discussion. > > Wietse It looks very much like clampsmtp was giving the 250. I've disabled it and so far this afternoon it's CNR. I'll look to reconfigure what I'm doing with clam. Basically the clam content filter has OK'd it but the upstream spam milter rejected it. All that to one side, is there any way to stop the generation of NDR's period - or to have them 'redirected' to a local target? I do appreciate this is a sensitive subject, but I would rather have the option not to generate them in the first place.
Re: Bounce / NDR messages - how to stop them
On Mon, 2009-06-29 at 19:41 +0100, Steve wrote: > On Mon, 2009-06-29 at 14:29 -0400, Charles Marcus wrote: > > On 6/29/2009, Steve (steve.h...@digitalcertainty.co.uk) wrote: > > > You are, of course, correct. It would be totally retarded to be able to > > > switch of bounce/ndr messages. > > > > Yes, it would, since it breaks smtp... > > So does the notion of 'Before Queue Filtering'. I think it goes > something like 'You must decide to accept or reject a message before the > DATA command'. > > Are we *selective* in the parts of the SMTP RFC's we adhear to? > And this come to think of it: strict_rfc821_envelopes We can disable. So what is the bid deal about disabling Postscatter?
Re: Bounce / NDR messages - how to stop them
On Mon, 2009-06-29 at 14:56 -0400, Charles Marcus wrote: > On 6/29/2009 2:41 PM, Steve wrote: > >>> You are, of course, correct. It would be totally retarded to be able to > >>> switch of bounce/ndr messages. > > >> Yes, it would, since it breaks smtp... > > > So does the notion of 'Before Queue Filtering'. I think it goes > > something like 'You must decide to accept or reject a message before the > > DATA command'. > > > > Are we *selective* in the parts of the SMTP RFC's we adhear to? > > Nope, just able to read... > > http://www.postfix.org/SMTPD_PROXY_README.html > Me to. RFC821, in particular; "The DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources are not available." So as far as I can see rejecting mail after the data command is munging the RFC's to provide a feature with the MTA. So why is there a problem in providing a feature to turn of Postscatter in the event of an admin making a minor balls up in using a feature that already munges the protocol in any case? As for the strict envelopes - providing the ability to turn of parts of the RFC Envelope is also providing a feature for the MTA. It's selecting parts of the RFC by desire. It's a pretty good feature and makes sense. Much like being able to turn *off* Postscatter. As far as the header/body content checks go - not being able to white list or exempt from those is really retarded. That said, these too are RFC breakers really. It's hard to scan the body before the DATA is given so 'REJECT' in a body check would be RFC breaking; "The DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources are not available." Let's just check: No recipients - no, we don't accept mail for invalid recipients or we start Postscattering Resources not available - no. We had plenty of resources to scan the message, we have space on the disc. We don't want it because of the content. That means we are not adhearing to the RFC's. So we **ARE** being selective about how we apply them. I'm sorry to bring it up. Perhaps I don't read as well as you do. I'm sorry we don't agree. We have different opinions. It's a war nobody will ever win. To me, if you can selectively mung some parts of the protocol to suit, you can't really jump up and down when other people ask for other things to be munged.
