Re: anti spam measures
Roman Gelfand put forth on 1/3/2010 3:44 PM:
> I do train DSPAM and it works great. However, if I could block it
> before it gets to DSPAM, why not. I wouldn't feel bad if exchange
> told me this is perfectly good email. I am, looking, to do away with
> exchange server altogether.
Is managing local block lists above your "effort threshold"? If the answer is
no...
I've been building some local lists for about 1.5+ years now and it has pretty
much completely clobbered my snowshoe problem. I get one to two spams a day in
the inbox these days, if that. I go many days in a row with none. Every few
weeks or so I'll see 5-10 spams in the inbox due to a run from a previously
unknown snowshoe spammer IP or /27 or /24 range. I block it and sail mostly
spam free again for another few weeks.
I don't use any content filtering software, period, only smtpd checks, postgrey
daemon, and zen.spamhaus.org. I filter about 10 countries and all of Africa
using ipdeny.com cidr blocks and I do some rdns name regex rejections.
Interestingly, I've not had a rejection from spamhaus in months. Heck, I don't
even know if Postfix is querying zen anymore. I've nothing of zen in my logs
since Sept 25, 2009. Postfix only logs zen rejections, not unsuccessful lookups
(at my default logging level anyway).
Anyway, I'm almost entirely spam free, whilst making use of no content filtering
or dnsbls (although I do have on dnsbl configured, as mentioned previously). I
run a small vanity server so YMMV. It's a pretty simple A/S setup but very
effective. ~/spammer is my main anti-snowshoe file, mostly US IP space. It
currently has 789 netblocks listed from /29s to a /12. I heard your gasp "Uahh!
You block a /12? OMG! OMG!. This /12 happens to belong to a cable ISP:
OrgName:Mediacom Communications Corp
CIDR: 173.16.0.0/12
NetName:MEDIACOM-RESIDENTIAL-CUST
It was not in spamhaus PBL or any other "dynamic IP" dnsbls at the time I
blocked it. It's entirely residential and should be policy blocked. Anyway,
here's my config in case you may any of it useful. I can provide static block
lists in off list email or on a web page if you like.
header_checks = pcre:/etc/postfix/header_checks
mime_header_checks = pcre:/etc/postfix/mime_header_checks
smtpd_helo_required = yes
cidr=cidr:/etc/postfix/cidr_files
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/whitelist
check_sender_access hash:/etc/postfix/whitelist
check_client_access hash:/etc/postfix/whitelist
check_client_access hash:/etc/postfix/blacklist
check_client_access regexp:/etc/postfix/fqrdns.regexp
check_client_access pcre:/etc/postfix/ptr-tld.pcre
check_client_access ${cidr}/countries
check_client_access ${cidr}/spammer
check_client_access ${cidr}/misc-spam-srcs
reject_unknown_client_hostname
reject_non_fqdn_sender
reject_non_fqdn_helo_hostname
reject_invalid_helo_hostname
reject_unknown_helo_hostname
reject_unlisted_recipient
reject_rbl_client zen.spamhaus.org
check_policy_service inet:127.0.0.1:6
--
Stan
Re: whitelisting incoming /outgoing mail
Eric Williams put forth on 1/5/2010 8:02 AM: > I would like to apply the same access list so that users sending mail through > this server can only reach those same domains. > > I've tried lots of recipient checking configs but nothing works so far. I'd > rather not do this with the firewall, keeping the whitelist monitored by > postfix only. So you want a dedicated smtp relay server that will only transfer mail between a handful of domains? -- Stan
Re: ssh tunnel triggered on usage?
On Thu, 7 Jan 2010 00:49:23 -0800, Dennis Carr wrote: > 1) A better way to do this, using already existing mechanisms in > Postfix, or... Myabe have a look at this and tweak your server as necessary: http://www.hardwarefreak.com/postfix-adsl-relay-config.txt -- Stan
Re: Huge active queue and system idle, not delivering
On Fri, 08 Jan 2010 15:24:25 +0200, Patrick Chemla > When I telnet a70.localpc2105.com 25 I get an immediate response. I assume you are telnet'ing from the Postfix server with the queue delay problem. At this point, after you receive the 220, type: ehlo your.postfix-server.tld and time the delay of the 250 responses. Continue to do a complete manual mail transaction through telnet, and time each smtp command completion (wall clock is fine). Post the results here please. -- Stan
Re: Sender based relay server
Jack Knowlton put forth on 1/9/2010 9:57 AM: > Hi all. > Our internal postfix server relays all outbound mail thru an external host. > How can I set it to use a different relay server when the email comes from > a specified domain? Eg. j...@domain1.com -> xxx.xxx.xxx.xxx (default), > m...@domain2.com -> yyy.yyy.yyy.yyy This might help ya: sender_dependent_relayhost_maps (default: empty) A sender-dependent override for the global relayhost parameter setting. The tables are searched by the envelope sender address and @domain. A lookup result of DUNNO terminates the search without overriding the global relayhost parameter setting (Postfix 2.6 and later). This information is overruled with relay_transport, sender_dependent_default_transport_maps, default_transport and with the transport(5) table. For safety reasons, this feature does not allow $number substitutions in regular expression maps. This feature is available in Postfix 2.3 and later. -- Stan
Re: Huge active queue and system idle, not delivering
Patrick Chemla put forth on 1/9/2010 11:17 AM: > Hi all, > > I got these statistics: > > Jan 9 19:15:21 postfix postfix/scache[18038]: statistics: start > interval Jan 9 19:09:03 > Jan 9 19:15:21 postfix postfix/scache[18038]: statistics: domain lookup > hits=110 miss=89 success=55% > Jan 9 19:15:21 postfix postfix/scache[18038]: statistics: address > lookup hits=0 miss=2492 success=0% > Jan 9 19:15:21 postfix postfix/scache[18038]: statistics: max > simultaneous domains=1 addresses=4 connection=4 > > > What means miss=89 success=55%, miss=2492 success=0%? http://www.postfix.com/CONNECTION_CACHE_README.html -- Stan
Re: Huge active queue and system idle, not delivering
Patrick Chemla put forth on 1/9/2010 11:07 AM: > Hi, > > I will try all your advises, but something still very strange for me: > > We see that postfix logs show that ehlo process is very slow through > postfix but very fast by hand. Even I have recorded through > tcpdump/WireShark and I can see that messages are sent very very very > quickly in about 1 second. > > But still messages are sent at a rate of a dozen in 10 seconds. That > means that messages are sent 1 by one. > > If connexion to qmail servers are slow, or if qmails are mis-parameted, > too slow or anything else, When I do netstat -apn |grep :25 I get only a > few connexions from postfix server to qmail servers. Even if DNS+EHLO > are slow, and more, because DNS+EHLO seem to be slow, why I don't see > hundreds TCP connexions ESTABLISHED ? This behavior is likely a result of the connection cache: http://www.postfix.com/CONNECTION_CACHE_README.html If one has a large amount of mail destined for a single host, it is inefficient to open dozens or hundreds of TCP connections and SMTP connections due to the additional overhead of process/thread count and memory consumption. It is much more efficient to pipeline all the mail through a single connection. One can only pump so many bits down the wire between two hosts. If you can fill the pipe to near capacity with one TCP/SMTP stream, why open 100s of connections to do the same? I believe this is why you are not seeing dozens or hundreds of TCP connections. Postfix is intelligently designed to avoid this inefficiency. > I expected that postfix will deliver on 30 qmail servers at the same > time, and should manage hundreds parallel deliveries, hundreds parallel > connexions. Is there some parameter or some conception rule that refrain > him to do so? > > I expected that postfix will full up his own CPU/memory creating these > parallel delivery processes or/and will wait after the qmail servers, > but on all servers at the same time, on multiple connections to each one. > > Am I correct ? or I am dreaming of another mail transport package? > > Patrick As Victor and others have already stated: 1. In your previous configuration, you had multiple thousands of unique IP addresses (your customers) connecting directly to your 30 qmail servers to relay their mail. qmail performed fine with this configuration because no one qmail server was seeing thousands of delivery attempts per minute from any one single IP address. 2. In your current Postfix configuration, your qmail servers are seeing a single unique IP address attempting to send multiple thousands of messages per minute, and qmail is reacting with rate limiting countermeasures because of this. You need to figure out what settings in the qmail configuration are controlling this rate throttling and in what way. Once you find this and change it, you should see a dramatic improvement in Postfix's ability to quickly move the mail out of the queue to the 30 qmail servers, most likely using a single or only a few TCP connections to each qmail server. -- Stan
Re: Huge active queue and system idle, not delivering
Patrick Chemla put forth on 1/9/2010 12:37 PM: > I wen t there but did not find explanations about miss address lookup or > miss domain lookup. > While I have 122,000 messages in active queue I still don't understand > why statistics show max simultaneous domains=1. It should be dozens , or > hundreds. Those are statistics relating to scache performance. It tells you how many domains or addresses were able to be delivered via scache reuse. I.e. how many emails Postfix was able to send through an already open SMTP connection to a given host. Since all of your qmail hosts are configured identically, and should be able to relay mail bound for any destination on the internet, you should never see anything less than ~100% in those statistics, _unless_ there is some other kind of problem. If your qmail servers are rate limiting via any method, and Postfix is attempting to send 2000 emails per minute down that one SMTP connection, when qmail blocks individual deliveries for any reason, those scache failure statistics will increase. -- Stan
Re: Huge active queue and system idle, not delivering
Patrick Chemla put forth on 1/9/2010 1:08 PM: > You mean 100% success? Yes. > Before I set up the postfix relay to load balance between 30 qmail > servers, each of them was able to accept in his own queue hundreds > thousands email. Email were sent by campaigns of thousands balanced on 3 > qmails servers, each one full in CPU/memory working hard to deliver. > > Instead of sending each campaign on only 3 qmails, I though that by > sending each campaign on 30 qmails I will cut each one load by ten and > speed up deliveries. But now, postfix is retaining the emails in his own > queue, not pushing the queue down to the qmails. An admiral technical goal. Can you elaborate on these "campaigns"? You said previously that you had hundreds of thousands of customers whose email you were relaying, as if you are an ISP. Now you are saying the mail load is generated by "campaigns". What exactly are these campaigns? > Postfix server and qmail servers are all about 90%cpu free. only 1 to 9 > connexions exist at a time from postfix to qmails. This is because the qmail servers won't let the postfix server send any faster. We've been over this mulitple times now. Multiple people have told you the same thing. For this to work correctly, you need to figure out why the qmail servers are rate limiting the postfix server deliveries. > This is exactly what I would like to append: Instead of a queue of > 122,000 on postfix, I expect to have each qmail with a queue of 4000. > > Qmails did this before I set up postfix. All MTAs have unique performance characteristics. You've changed one of the MTAs in your architecture. Now you must re-tune your qmail farm servers to work with the new MTA, postfix, which you have introduced. This is kinda IT 101 stuff. You can't automatically assume the problem lies with the "new thing" you introduced. Often, the "new thing" exposes problems or weaknesses that already existed in the old stuff. -- Stan
Re: Huge active queue and system idle, not delivering
Patrick Chemla put forth on 1/10/2010 3:00 PM: > Wietse, >>> Please try the following, as asked half a week ago: >>> >>> postconf -e smtp_connection_cache_on_demand=no >>> postfix reload >>> >>> and report if this makes a difference. >>> Wietse >>> > I have tested this since yesterday night. > > I got some problems with Linux per user number of processes limit. I > fixed it. I also increased some delivery concurrency figures, and now I > can see up to 1300 processes delivering emails to the qmail servers. > > I had a few minutes shot today at a rate of 6300 emails per minute. I > ran a full hour at 180,000 emails per hour. The outbound line was > saturated. > > CPU is about 30% loaded, no Wait I/O, no swap, memory is large. > > I think I will reach about 600,000 emails per hour if I fix some timeout > on the qmails (replace by postfix?). Maybe I could reach 1 million? > > The full architecture that I plan will include 2 to 3 clustered postfix > relays and 50 2nd level qmails(or postfix) delivery servers, each with 3 > to 5 IP addresses, and upgraded outbound internet connection. > > With your help, I better understand now the impact of timeout and > concurrency parameters. In fact, delivery was blocked because postfix > was trying to reuse connections, so was waiting each email to complete > to send the next one. Also, because hundreds processes were created at > start time to manage inbound messages, there were no slots to fork > processes to deliver messages on the other hand. Same problem caused > very slow DNS and EHLO, because no available slots to fork. > > Of course, if you want me to post my conf, I will with pleasure. > > Many thanks to you, to Victor and Stan. > > Patrick On a technical level I'm happy you got it working. Just please tell us you're not sending mass spam with this setup. -- Stan
Re: Huge active queue and system idle, not delivering
Patrick Chemla put forth on 1/11/2010 1:02 AM: > Le 10/01/2010 23:58, Stan Hoeppner a écrit : >> On a technical level I'm happy you got it working. Just please tell >> us you're >> not sending mass spam with this setup. >> >> -- >> Stan >> > > I have to do it for a customer who send as he said, only opt-in mass > emails. He has a big blacklisted email database where he keeps all > unsubscribe messages. He said he has the right filters not to send > unwanted emails. Sigh... This doesn't pass the sniff test. I fear we've helped enable the sending of mass UBE. Patrick would you mind providing the IP netblock(s) you will be sending these mass mailings from? Or provide them to me off list please? Thanks. -- Stan
Re: Does Postfix cache resolv.conf? [SOLVED]
Christoph Anton Mitterer put forth on 1/11/2010 5:31 PM: > Using the "resolvconf" package, should solve your problems, the Debian > postfix package ships rules for resolvconf in order to automatically > update the chroot resolv.conf. resolvconf has a long list of conflicts including ifupdown and bind8/9. I've heard of some folks running bind locally on their (large) mail servers for dnsbl lookups (yes, instead of rbldnsd) and other purposes. Would using resolvconf break bind? Aptitude seems to suggest this. Does one need to be extra careful if/when installing this package? What kind of collateral damage does this pagkage cause, if any? Conflicts: bind (< 1:8.3.4-1), bind9 (< 1:9.2.1-7), dhcp-client (= 3.0.1betaRC4-1), dhcp-client (< 2.0pl5-18), dhcp3-client (< 3.0+3.0.1rc11-5), dhcpcd (< 1:1.3.22pl4-7), divine, dnsmasq (< 1.13-2), ifupdown (< 0.6.4-4.1), laptop-net (< 2.21-1), pcmcia-cs (< 3.2.5-1), pdnsd (< 1.1.10par-4), pppconfig (< 2.3.1), pppoeconf (< 1.0), pump (< 0.8.15-1), runit (< 1.8.0-3), totd (< 1.4-4), udhcpc (< 0.9.8cvs20050124-3), webmin (< 1.150-2), webmin-wvdial (< 1.160-3), whereami (< 0.3.3), xisp -- Stan
Re: Auto-whitelist policy
Daniel L. Miller put forth on 1/11/2010 5:03 PM: > Does anyone have an auto-whitelisting policy daemon? I want to have a > test early in sender checks that would bypass most of my other spam > prevention if a sender is in the whitelist - and have that whitelist > automatically updated by internal users sending to those remote senders. sed -n -e '/postfix\/smtp\[.*status=sent/s/^.*to=<\([^>]*\).*$/\1/p' /var/log/mail.log | sort -u Thank Victor. He answered this in 2004. It was the 2nd hit in google. Now all you have to do is take the output of this, say daily, and do a compare/append to the whitelist file you're maintaining. -- Stan
Re: multiple PTR records
Frank Cusack put forth on 1/12/2010 12:04 PM: > I don't know why you would thank Wietse when there is no disadvantage > to accepting multiple PTR records. There is only a downside. What's the downside Frank? -- Stan
Re: multiple PTR records
Frank Cusack put forth on 1/12/2010 12:12 PM: > On January 12, 2010 12:09:28 PM -0600 Stan Hoeppner > wrote: >> Frank Cusack put forth on 1/12/2010 12:04 PM: >> >>> I don't know why you would thank Wietse when there is no disadvantage >>> to accepting multiple PTR records. There is only a downside. >> >> What's the downside Frank? > > Good question. > > I can't accept mail from hosts with multiple PTR records without manually > whitelisting them. Additionally, I can't even tell that I'm experiencing > a failure until it is reported to me "manually" and out of band. Have you tried Sendmail, Exim, Qmail and/or other MTAs? Do any/all of them handle this "problem" "correctly" for you? If so, why are you not using them, instead of asking Wietse to "fix" something that he (and most others) don't consider "broken"? I'm somewhat new to the game. I've only been running Postfix since Q4 '05. In that time I can't recall ever having the issue you describe. It sounds like you have this problem often. Why is that? Who are all of these sites/orgs sending you mail from hosts with multiple PTRs? Can you cite a few examples of such hosts so I can investigate? -- Stan
Re: Challenge/Response
Noel Jones put forth on 1/12/2010 12:50 PM: > On 1/12/2010 12:39 PM, Aaron Clausen wrote: >> Are challenge response systems still heavily frowned on? >> > > Yes. Yes. -- Stan
Re: multiple PTR records
Frank Cusack put forth on 1/12/2010 2:29 PM: > Not to be rude, but I'm not sure why you asked me the question in the > first place. It was in fact a great question. Your response however > was merely to dismiss my problem. So it seems like your question was > just rhetoric designed to sink this discussion into non-technical mush. > I apologize if that wasn't your intent. Initially I shoved back a bit I guess because you seemed to enter in attack mode with fangs out ripping Postfix a new one, so to speak. I think you were probably just venting frustration, which is understandable. I thought I was pretty restrained. ;) > Is it your opinion that the disadvantages I've described aren't valid? When it comes to multiple PTRs on a single email emitting IP, yes, it is my opinion that that the disadvantages you describe are not valid. As a matter of fact, I don't know of a scenario that would *require* an email emitting IP to have multiple PTRs. Can you post such a scenario? -- Stan
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
Frank Cusack put forth on 1/12/2010 9:46 PM: > I think it all ended well though? Except my problem still exists. :\ We know things break when that hosts sends mail to you. What happens when you send mail to that host? Do you see the same disconnect problem or similar? What were the results of tcpdump? -- Stan
Re: Forged MAIL FROM issue
Alexandru Florescu put forth on 1/13/2010 7:33 AM: > > permit_mynetworks, > > Is some option missing? What can I do to prevent this? I found it because I > received spam in this way. > > Using postfix 2.3.3 on Centos 5.4. I'm guessing your telnet client machine is within mynetworks. If so, none of your other checks are valid and any/all mail sent via this telnet is thus accepted regardless of mail from: forgery. -- Stan
Re: Bounces
Dhiraj Chatpar put forth on 1/13/2010 3:21 PM: > Dear All, > > What string or what configuration to use in postfix in order to not > receive any bounces at all. I mean incase there is a bounce it should > not be returned back to the sender who initiated the mail. > > I am sure there is a way to achieve this in postfix http://www.postfix.org/bounce.8.html -- Stan
Re: Bounces
Dhiraj Chatpar put forth on 1/13/2010 3:31 PM: > Yes, But which parameter to use in order to stop bounces totally and how? Please don't top post. You may try commenting out the bounce daemon in master.cf and restarting Postfix. bounceunix - - - - 0 bounce #bounceunix - - - - 0 bounce There may be a better or more optimal way to do this. If so one of the devs or more seasoned OPs may help you. -- Stan
Re: Pflogsumm Status
Joe put forth on 1/13/2010 9:35 PM: > Jim Seymour wrote: >> Hi All, >> >> >> I'm working on a new release even now. More information to >> follow in a day or two. > > That is great news - looking forward to your next release. It's a useful > tool indeed. Seconded. I use it daily, although I'm probably a few revs behind. (Debian/Lenny 1.1.0-3) -- Stan
Re: Speeding up Local Delivery
Wendigo Thompson put forth on 1/14/2010 6:39 PM: > Okay, I have some updates. Reducing the concurrency down (and > ultimately to 1) increased performance: it seems the delays I was > seeing were related to concurrency inside SQL. However, I am still > seeing half second delays in local delivery while my insertion > application is showing ~.003s processing times. I was able to verify > that it's not my insertion application by making a simple script that > soft-bounces mail (exit code 75) and does nothing else -- there's > still a half a second delay on action. Tracing the individual > processes is proving to be a challenge as this is an Apple system and > dtruss can only be run as root. Any tips? Not specifically. I was just going over the numbers, and with your previous configuration, before the current tweaking, the db process was consuming each email in about 10-20 seconds, which is extremely long but for large PDFs, Word docs, or binaries. Lets say the average was 10 seconds. If concurrency was 1, that comes out to ~34 days to consume 300,000 emails, if my math is correct, at 86,400 seconds per day. Obviously your concurrency was a little higher than 1. ;) > Jan 14 18:30:58 x postfix/local[27253]: 03B2A13E351: to=, > relay=local, delay=40172, delays=37592/2580/0/0.51, dsn=4.3.0, > status=deferred (temporary failure) > Jan 14 18:30:59 x postfix/local[27253]: 03B31132541: to=, > relay=local, delay=70394, delays=67813/2581/0/0.53, dsn=4.3.0, > status=deferred (temporary failure) > Jan 14 18:30:59 x postfix/local[27253]: 03B371416A7: to=, > relay=local, delay=36726, delays=34144/2581/0/0.53, dsn=4.3.0, > status=deferred (temporary failure) > Jan 14 18:31:00 x postfix/local[27253]: 03B3714401A: to=, > relay=local, delay=34562, delays=31980/2582/0/0.54, dsn=4.3.0, > status=deferred (temporary failure) It appears you've now dropped the db process consumption time down from ~10 seconds per email to about .5 seconds per email, a speedup of ~20:1. All things being equal, we could assume you'll start seeing messages sitting in the queue for a little over an hour now instead of a day, once things settle down. This is still pretty high. Due you have the postfix queue and the db files spread across more than one spindle? I ask because the xServe doesn't have an inbuilt RAID controller (optional card), and only has 3 disk bays for slow (7200rpm) SATA disks. The db insertion time seems to hint that disk throughput may not be an issue for the db subsystem. If you have the db files sitting on fast external RAID or SAN storage, but have the postfix queue on the single system boot disk along with a page file partition, etc, this may explain why you're sync'ing so quickly to db yet it takes so long to pipe the emails to the db insertion app. Your queue disk may not be fast enough for the load being generated on it. This one disk is trying to pump ~600,000 messages/day (in+out), and most of that will peak during two or three 1-2 hour intervals during the business day--arrival, after lunch, end of day. -- Stan
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
Frank Cusack put forth on 1/17/2010 2:47 PM: > On January 17, 2010 12:37:46 PM -0800 "Daniel V. Reinhardt" > wrote: >> A proper ISP and Host would have the proper PTR Records set up thus >> validating the said sender as being part of a reputable ISP or Host. >> Most of the spammers I have come across have improper DNS Records set up >> meaning no name lookup based on IP address e.g 127.0.0.1 returns nothing. >> So rejecting email email by PTR Records is a spam prevention thing. > > Five years ago, yes. Have you been in prison or incapacitated for the last few years Frank? You seem to be out of touch with many established standards/norms. First you argue for multiple PTR records for mail sending hosts. Then you argue that no PTR should be required for mail sending hosts. You've just proposed both extremes of the debate, yet the debate on this was over long ago, and everyone else is right in the middle: one PTR required for a mail sending host. Rejecting mail due to lack of a PTR is an anti bot spam tactic. It is as prevalent today as it was 5 years ago, but probably less effective. Many ISPs went PTR crazy, assigning them to all their dynamic consumer IP ranges. DULs and generic PTR regexes are now more effective in this regard. Even so, there are still large amounts of consumer IP space without PTRs, so this tactic is still valid, and still widely used. -- Stan
Re: Postfix sender reputation support in snapshot 20100117
Victor Duchovni put forth on 1/17/2010 5:43 PM: > On Sun, Jan 17, 2010 at 05:38:12PM -0500, Wietse Venema wrote: > >> According to discussions on the Postfix list there is a legitimate >> need for such functionality. Until now this requires one Postfix >> instance per source IP address. > > I am not entirely convinced the need is "legitimate", as this probably is > most useful for "snow-shoe" spam operations. > > This said, it is not clear that having snow-shoe spammers using Postfix > is any worse then snow-shoe spammers using Sendmail, Qmail, Exim or > various commercial engines... > > So long as the feature is reasonably useful to some non-spammers, we can > fight spam by means more effective than trying to deny them software... I tend to agree. There are a lot of snowshoe OPs out there, and they're already using some smtp mailer engine successfully. I don't think this new feature is going to create a mad rush of spammers adopting Postfix just for this. -- Stan
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
LuKreme put forth on 1/17/2010 5:55 PM: > On Jan 17, 2010, at 13:37, "Daniel V. Reinhardt" > wrote: >> So rejecting email email by PTR Records is a spam prevention thing. > > Can you back this up at all? It's certainly not true in my experience > and hasn't been true in a long time. Then I'd surmise your experience is very limited. Join spam-l and ask this naked PTR question. You will be clued. -- Stan
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
LuKreme put forth on 1/18/2010 12:46 AM: > On Jan 17, 2010, at 17:27, Stan Hoeppner wrote: >> Then I'd surmise your experience is very limited. > > I have only been running a mailserver for 17 years or so. Do you use either of these restrictions? reject_unknown_client_hostname reject_unknown_reverse_client_hostname -- Stan
Re: Rejecting an address with our MX
Frank Bonnet put forth on 1/18/2010 4:19 AM: > Hello > > I wonder how to reject a particuliar address at MX machine > > actually I use : > smtpd_sender_restrictions = > \check_sender_access hash:/usr/local/etc/postfix/sender_access Do you want to reject an email address, or an IP address? If email address, then what you have above should do it. Get rid of that backslash. And be sure you always postmap hash tables when you create or edit them: host:/# postmap sender_access And if you haven't reloaded postfix since creating this restriction host:/# /etc/init.d/postfix reload -- Stan
Re: The method behind the madness
Daniel L. Miller put forth on 1/18/2010 12:51 PM: > A point - and a good one for initialization of the whitelist. However, > this does not address the need to add new addresses to the list > automatically. Example - our company changes insurance brokers, and > needs to receive forms from the new broker. Such communications should > not be reliant on the IT department "unlocking" the mail server - just > the act of the office manager's sending an e-mail to the broker should > be sufficient. Daniel, it seems you're looking for feature perfection in rev. 0.1.1 of an as yet created home brew software solution. Do you think you might be setting your sights a bit high? Is this because you already have a solution that does all these things perfectly, and you're _expecting_ your new home brew solution to do the same right from the start? If you _need_ a home brew solution _now_, start small and inelegant, getting most of the functionality you want/need. This can be done with simple scripts and cron. After it's working relatively well, _then_ spend time creating the "elegant" solution. JMHO. -- Stan
WAS: The method behind the madness NOW: simple Postfix auto whitelist
Daniel L. Miller put forth on 1/18/2010 1:30 PM: >> If you _need_ a home brew solution _now_, start small and inelegant, >> getting >> most of the functionality you want/need. This can be done with simple >> scripts >> and cron. After it's working relatively well, _then_ spend time >> creating the >> "elegant" solution. JMHO. >> > > But the main thing is having OP-maintained lists is exactly what I'm > trying to avoid and completely misses the point of having an > auto-whitelist. How is the above mentioned solution an "OP-maintained" list? The scripts and cron scheduling would be OP maintained (not much time expended after initial setup) but once setup the white listing is fully automated. As an example... Add in the appropriate place in main.cf check_sender_access hash:/etc/postfix/auto-whtlst Set your log rotation for 24 hours so you never have a huge /var/log/mail.log file to process. Touch /etc/postfix/auto-whtlst and /etc/postfix/auto-whtlst.raw. Create a script something like this: /usr/bin/whtlst_gen.sh #! /bin/sh # [1] grab all sent to addresses from the current mail log sed -n -e '/postfix\/smtp\[.*status=sent/s/^.*to=<\([^>]*\).*$/\1/p' /var/log/mail.log | sort -u > /tmp/sender_addrs.tmp # merge the new addresses with the current list, eliminate dups cat /tmp/sender_addrs.tmp /etc/postfix/auto-whtlst.raw | sort | uniq > /tmp/wrkng-whtlst.tmp # keep a copy without "OK" action for next processing iteration cp /tmp/wrkng-whtlst.tmp /etc/postfix/auto-whtlst.raw # add "OK" action to each entry, generating new list file sed 's/$/ OK/g' /etc/auto-whtlst.raw > /etc/postfix/auto-whtlst # regenerate hash /usr/sbin/postmap /etc/postfix/auto-whtlst I'm not a script god, and this could obviously be optimized. I've intentionally split some things out for easy(er) reading. That said, cron this script or something similar to run every 5 to 10 minutes, or as often as the OP deems necessary. On modern hardware, if this site has a moderate mail stream, this script will execute pretty quickly (seconds) and generate minimal system load for a short duration. The above script is a concept only, something I just whipped up. I would think it should work with little modification. Once implemented, something like this will be fully automatic. It implements crude sender address verification as it only grabs addresses logged with status=sent. It's not "optimal" or "real time" or "elegant", but is simple, easy, quick to implement, and doesn't burden the system. I would think it would give the OP at least 90%+ of what he's looking for wrt the requested functionality, although it does introduce slightly increased exposure to forged sender address spam. -- Stan [1] Viktor Duchovni contributed the first sed line of this script back in 2004
Re: The method behind the madness
Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM: > I have achieved this with a slightly hacked TMDA (www.tmda.net). if you > want my modifications, contact me off-list. I'm surprised you actually mentioned a solution whose core feature is challenge/response. C/R is one of those "cures" that far is worse than the disease. -- Stan
Re: The method behind the madness
Mark Nernberg (gmail account) put forth on 1/18/2010 4:50 PM: > > > On Jan 18, 2010, at 17:48, Stan Hoeppner wrote: > >> Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM: >> >>> I have achieved this with a slightly hacked TMDA (www.tmda.net). if you >>> want my modifications, contact me off-list. >> >> I'm surprised you actually mentioned a solution whose core feature is >> challenge/response. C/R is one of those "cures" that far is worse >> than the disease. >> >> -- >> Stan > > I got rid of the C/R ... I wanted auto whitelisting & some of the other > features. hence my modifications. From: http://tmda.sourceforge.net/cgi-bin/moin.cgi/TmdaFaq#head-0b1aee3c2decf32a26ffcc12b397f9d3cec3fdc0 How do I setup an "auto-whitelist"? TMDA has the ability to automagically add confirmed addresses to a whitelist. This way, each new sender only has to go through the confirmation process once. ... Then TMDA will the add the senders from successfully confirmed messages to the 'whitelist_confirmed' file. A possible variation on this includes setting CONFIRM_APPEND to your main whitelist file rather than a secondary file. This strongly suggests the auto-whitelist feature will not function in the absence of the C/R feature. Put another way, the auto-whitelist function is dependent upon the C/R function. Senders must reply to the challenge email in order to be added to the whitelist. Am I reading this wrong? -- Stan
Re: Changes in PCRE handling postfix etch vs lenny?
Well, there's one positive side to this thread Noel. Your reply to "undisclosed recipients" instead of the list address broke my postfix-users sort filter. I just spent 20 minutes trying to figure it out. I tried "received" and "return-path" and all kinds of header checks in the T-Bird message filter, and none of them work on this message. They clearly should. So now I get to file a bug report on T-Bird as it's clearly not processing the headers correctly or obeying "custom" headers I plug in. Hell, it won't even filter on Sender: owner-postfix-us...@postfix.org for Pete's sake and Sender is built into the filter, not custom, IIRC. Regardless of the T-Bird issue, could we all please reply to the list address instead of burying it in a BCC? That's just plain silly. Thanks. -- Stan
Re: Changes in PCRE handling postfix etch vs lenny?
/dev/rob0 put forth on 1/19/2010 10:41 AM: >> I have to manually install postfix-doc to find a >> /usr/share/doc/postfix/RELEASE_NOTES.gz file. > > This is worth complaining about, IMO. If a user should make the > conscious decision to not install the documentation with a given > package, that's the user's fault, but the default install should > provide documentation. I didn't do anything special when I upgraded from Etch to Lenny some many months ago in 2009, and I have all the docs. I upgraded via aptitude from the mirrors. If the OP upgraded via local media (CD/DVD) I guess it's possible the routine is somehow different, but I doubt it. The docs are all zipped but they're all here, including the RELEASE_NOTES. greer:/home/stan# la /usr/share/doc/postfix/ total 604K drwxr-xr-x 4 root root 4.0K Oct 3 06:21 . drwxr-xr-x 446 root root 12K Jan 18 20:52 .. drwxr-xr-x 2 root root 4.0K Oct 21 2005 examples drwxr-xr-x 2 root root 4.0K Oct 3 06:21 html -rw-r--r-- 1 root root 2.9K Sep 14 2008 ADDRESS_CLASS_README.gz -rw-r--r-- 1 root root 11K Sep 14 2008 ADDRESS_REWRITING_README.gz -rw-r--r-- 1 root root 5.4K Sep 14 2008 ADDRESS_VERIFICATION_README.gz -rw-r--r-- 1 root root 4.3K Sep 14 2008 BACKSCATTER_README.gz -rw-r--r-- 1 root root 6.8K Sep 14 2008 BASIC_CONFIGURATION_README.gz -rw-r--r-- 1 root root 4.3K Sep 14 2008 BUILTIN_FILTER_README.gz -rw-r--r-- 1 root root 2.7K Sep 14 2008 CDB_README -rw-r--r-- 1 root root 2.9K Sep 14 2008 COMPATIBILITY -rw-r--r-- 1 root root 3.2K Sep 14 2008 CONNECTION_CACHE_README.gz -rw-r--r-- 1 root root 3.3K Sep 14 2008 CONTENT_INSPECTION_README -rw-r--r-- 1 root root 257 Sep 14 2008 CYRUS_README -rw-r--r-- 1 root root 4.5K Sep 14 2008 DATABASE_README.gz -rw-r--r-- 1 root root 2.3K Sep 14 2008 DB_README.gz -rw-r--r-- 1 root root 6.3K Sep 14 2008 DEBUG_README.gz -rw-r--r-- 1 root root 1.8K Sep 14 2008 DSN_README.gz -rw-r--r-- 1 root root 3.8K Sep 14 2008 ETRN_README.gz -rw-r--r-- 1 root root 7.8K Sep 14 2008 FILTER_README.gz -rw-r--r-- 1 root root 4.5K Sep 14 2008 IPV6_README.gz -rw-r--r-- 1 root root 7.0K Sep 14 2008 LDAP_README.gz -rw-r--r-- 1 root root 1.7K Sep 14 2008 LINUX_README -rw-r--r-- 1 root root 2.1K Sep 14 2008 LOCAL_RECIPIENT_README.gz -rw-r--r-- 1 root root 2.0K Sep 14 2008 MAILDROP_README.gz -rw-r--r-- 1 root root 7.9K Sep 14 2008 MILTER_README.gz -rw-r--r-- 1 root root 2.0K Sep 14 2008 MYSQL_README.gz -rw-r--r-- 1 root root 535 Sep 14 2008 NEWS.Debian.gz -rw-r--r-- 1 root root 1.6K Sep 14 2008 NFS_README -rw-r--r-- 1 root root 2.2K Sep 14 2008 PACKAGE_README.gz -rw-r--r-- 1 root root 2.9K Sep 14 2008 PCRE_README -rw-r--r-- 1 root root 2.1K Sep 14 2008 PGSQL_README.gz -rw-r--r-- 1 root root 1.2K Sep 14 2008 PORTING -rw-r--r-- 1 root root 234 Sep 14 2008 QMQP_README -rw-r--r-- 1 root root 13K Sep 14 2008 QSHAPE_README.gz -rw-r--r-- 1 root root 2.2K Sep 14 2008 README.Debian -rw-r--r-- 1 root root 2.5K Sep 14 2008 README.gz -rw-r--r-- 1 root root 1.4K Sep 14 2008 README.proto -rw-r--r-- 1 root root 5.8K Sep 14 2008 RELEASE_NOTES.gz -rw-r--r-- 1 root root 2.4K Sep 14 2008 RESTRICTION_CLASS_README.gz -rw-r--r-- 1 root root 7.3K Sep 14 2008 SASL_README.gz -rw-r--r-- 1 root root 20K Sep 14 2008 SCHEDULER_README.gz -rw-r--r-- 1 root root 5.0K Sep 14 2008 SMTPD_ACCESS_README.gz -rw-r--r-- 1 root root 6.2K Sep 14 2008 SMTPD_POLICY_README.gz -rw-r--r-- 1 root root 3.7K Sep 14 2008 SMTPD_PROXY_README.gz -rw-r--r-- 1 root root 4.1K Sep 14 2008 SOHO_README.gz -rw-r--r-- 1 root root 7.3K Sep 14 2008 STANDARD_CONFIGURATION_README.gz -rw-r--r-- 1 root root 6.0K Sep 14 2008 STRESS_README.gz -rw-r--r-- 1 root root 15K Sep 14 2008 TLS_LEGACY_README.gz -rw-r--r-- 1 root root 26K Sep 14 2008 TLS_README.gz -rw-r--r-- 1 root root 7.6K Sep 14 2008 TUNING_README.gz -rw-r--r-- 1 root root 1.8K Sep 14 2008 UUCP_README.gz -rw-r--r-- 1 root root 2.5K Sep 14 2008 VERP_README.gz -rw-r--r-- 1 root root 6.3K Sep 14 2008 VIRTUAL_README.gz -rw-r--r-- 1 root root 3.1K Sep 14 2008 XCLIENT_README.gz -rw-r--r-- 1 root root 2.9K Sep 14 2008 XFORWARD_README.gz -rw-r--r-- 1 root root 28K Sep 14 2008 changelog.Debian.gz -rw-r--r-- 1 root root 165K Sep 14 2008 changelog.gz -rw-r--r-- 1 root root 18K Sep 14 2008 copyright -- Stan
Re: The method behind the madness
Steve put forth on 1/19/2010 7:10 PM: > I have another opinion on that. The Anti-Spam solution I use has normally > 0.01 seconds (or less but could be more as well) per message when classifying > a mail for Ham/Spam. Every processing of a message allows me to increase the > accuracy of the solution. If the engine makes errors then I correct them and > the engine learns. Whitelisting all friends, family members, etc from the > beginning is taking away from me the possibility to get better results in the > future. I want my Anti-Spam engine to learn. I want it to work and get > better. I want it to learn who is my friend and who not. I want it to > whitelist my friends/family members only if they don't send me Spam. If the > engine thinks they send me Spam then I want the engine to adapt and learn. If > the solution is constantly making errors in that regard then this would not > tighten my confidence in the solution and I personally would soon look for > another solution. That's how I think about it. Don't get me wrong. I am not > saying tha > t my viewpoint is the only valid viewpoint and that yours is absolutely > wrong and and and. I just tried to bring closer to you how I see that topic > and how I handle it. Without judging which approach is the better one. I know > that any approach is right and in the same time wrong. There is none > universal valid approach. Many people don't use content filters in their anti-spam arsenals. For these folks (including myself) whitelisting is a valuable tool, and if done correctly won't introduce any additional exposure to spam via spoofed sender addresses. If you're gasping and wondering how someone can fight spam without a content filter such as SA, I'd say you haven't been in the game long enough, or haven't faced 4th and goal enough times. ;) I'll take some heat for this comment, but for the most part it's true. SA is a "lazy man's" A/S tool. Most people who use it expect it to just "work automatically". Some know that is must be well trained and tweaked to work very well. Others have thrown it away and gone to better methods, but they take considerably more OP time to setup and keep working well. I fall into another category. I've never used SA and started out from day one using the "other methods", including heavy use of Postfix's inbuilt anti-UCE features. And yes, I've burned a lot of time maintaining it. But it works very very well. -- Stan
Re: Changes in PCRE handling postfix etch vs lenny?
mouss put forth on 1/20/2010 2:26 PM: >> That's just plain silly. > > Keep calm Stan! I was calm. I had no exclamation point there. ;) > Consider this to be a good lesson: your filtering approach is > suboptimal. For most mailing lists, you can use one of: It _was_ less than optimal. > List-Id > List-Post > Sender I've got just Sender: now and it works fine. And up until your email in question, I'd never had a problem. > except maybe for some exceptions (but then suggest to the list admins to > implement the List-Id header). There's still a bug. After I fixed my rule to filter on Sender, and ran the filter, it absolutely would not pull your message into the appropriate folder, not matter what head I selected, and I tried them all, some 20 or so. Everything coming in after yours was pulled on "Sender: " into the postfix-users folder, but your message would not pull running the filter manually. _That_ is the bug. The filter was working on any new messages arriving in the inbox, but it wouldn't work on your message already in the inbox. And yes, I had the appropriate option selected to run the filter on messages already in the inbox folder. -- Stan
Re: Changes in PCRE handling postfix etch vs lenny?
Charles Marcus put forth on 1/21/2010 6:05 AM: > On 2010-01-19, Stan Hoeppner (s...@hardwarefreak.com) wrote: >> So now I get to file a bug report on T-Bird as it's clearly not processing >> the >> headers correctly or obeying "custom" headers I plug in. Hell, it won't even >> filter on Sender: owner-postfix-us...@postfix.org for Pete's sake and Sender >> is >> built into the filter, not custom, IIRC. > > What version of TBird? Are you using IMAP? > > TBird won't process custom headers on an IMAP account unless you have > the folder set to full offline mode (yes, I consider this a bug, and I > do believe there is at least one reported already, so be sure to search > before opening a new one). > > 'Sender' is not a built in header (in TB2 or 3.0), but 'From' is. > > So, if you're using IMAP, thats the bug. Thanks for the heads up. Yes, I'm using IMAP and TB3. So I'm sure this is the same bug. Interestingly, like I said, the filter on Sender works fine for newly arriving messages. It just doesn't work on messages already in the inbox when running the filter manually. I don't have offline mode configured. -- Stan
rbl check being skipped
I've wondered for a couple of months why my rbl check is being skipped. I've
not seen a spamhaus entry in my logs since Sept 25 '09. Interestingly, postgrey
is being called now and then, and it is after the rbl check in main.cf. Any
idea why my rbl check is being skipped? What have I screwed up to cause this?
postconf -n output:
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
inet_interfaces = all
message_size_limit = 1024
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = hardwarefreak.com
myhostname = greer.hardwarefreak.com
mynetworks = 192.168.100.0/24
myorigin = hardwarefreak.com
parent_domain_matches_subdomains = debug_peer_list smtpd_access_maps
proxy_interfaces = 65.41.216.221
readme_directory = /usr/share/doc/postfix
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
relay_domains =
smtpd_banner = $myhostname ESMTP Postfix
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks
reject_unauth_destination check_recipient_access
hash:/etc/postfix/whitelist check_sender_access hash:/etc/postfix/whitelist
check_client_access hash:/etc/postfix/whitelist check_client_access
hash:/etc/postfix/blacklist check_client_access
regexp:/etc/postfix/fqrdns.regexp check_client_access
pcre:/etc/postfix/ptr-tld.pcre check_client_access ${cidr}/countries
check_client_access ${cidr}/spammer check_client_access
${cidr}/misc-spam-srcs reject_unknown_client_hostname
reject_non_fqdn_sender reject_non_fqdn_helo_hostname
reject_invalid_helo_hostnamereject_unknown_helo_hostname
reject_unlisted_recipient reject_rbl_client zen.spamhaus.org
check_policy_service inet:127.0.0.1:6
strict_rfc821_envelopes = yes
virtual_alias_maps = hash:/etc/postfix/virtual
Including main.cf since I've got variables declared:
smtpd_banner = $myhostname ESMTP Postfix
biff = no
append_dot_mydomain = no
myhostname = greer.hardwarefreak.com
myorigin = hardwarefreak.com
mydestination = hardwarefreak.com
mynetworks = 192.168.100.0/24
proxy_interfaces = 65.41.216.221
relay_domains =
inet_interfaces = all
disable_vrfy_command = yes
message_size_limit = 1024
parent_domain_matches_subdomains =
debug_peer_list smtpd_access_maps
strict_rfc821_envelopes = yes
header_checks = pcre:/etc/postfix/header_checks
mime_header_checks = pcre:/etc/postfix/mime_header_checks
smtpd_helo_required = yes
cidr=cidr:/etc/postfix/cidr_files
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/whitelist
check_sender_access hash:/etc/postfix/whitelist
check_client_access hash:/etc/postfix/whitelist
check_client_access hash:/etc/postfix/blacklist
check_client_access regexp:/etc/postfix/fqrdns.regexp
check_client_access pcre:/etc/postfix/ptr-tld.pcre
check_client_access ${cidr}/countries
check_client_access ${cidr}/spammer
check_client_access ${cidr}/misc-spam-srcs
reject_unknown_client_hostname
reject_non_fqdn_sender
reject_non_fqdn_helo_hostname
reject_invalid_helo_hostname
reject_unknown_helo_hostname
reject_unlisted_recipient
reject_rbl_client zen.spamhaus.org
check_policy_service inet:127.0.0.1:6
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
alias_maps = hash:/etc/aliases
virtual_alias_maps = hash:/etc/postfix/virtual
readme_directory = /usr/share/doc/postfix
--
Stan
SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Stan Hoeppner put forth on 1/22/2010 1:28 AM: > I've wondered for a couple of months why my rbl check is being skipped. I've > not seen a spamhaus entry in my logs since Sept 25 '09. Interestingly, > postgrey > is being called now and then, and it is after the rbl check in main.cf. Any > idea why my rbl check is being skipped? What have I screwed up to cause this? Bad form replying to my own post but... After a hint from Ralf, I started digging around and here is what I found: 1. Spamhaus has banned Google Public DNS resolver queries. I didn't know this until today. If Postfix is using Google Public DNS resolvers, rbl queries to zen.spamhaus.org fail but Postfix (Debian Lenny 2.5.5-1.1) logs NOTHING about it. Not the query attempt, not the failure, zilch, nut'n. This explains why I haven't seen any zen entries in my log since Sept 25 last year, apparently the day I switched to Google DNS resolvers. A total lack of log entries makes troubleshooting anything very difficult. Thanks to Ralf's off list suggestion, I was able to start troubleshooting down the correct path. 2. For other dns resolvers that Spamhaus doesn't like, such as a few under the CenturyLink umbrella (former Embarq/Sprint resolvers) an error is logged, such as: Jan 22 05:27:53 greer postfix/smtpd[19251]: warning: 50.211.118.82.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=50.211.118.82.zen.spamhaus.org type=A: Host not found, try again 3. Sometime between my switch to the Google resolvers and today, Spamhaus decided to ban my previous Embarq resolvers. So, when I switched back to the old ones, I got errors like that above, and my zen queries still failed. I dug around through some very old paperwork and found a set of old Sprint resolvers in Kansas City I'd never actually used which aren't banned by Spamhaus. Turns out this is probably a good thing since the resolvers I found that work are also closest physically and electrically, the primary being 4 hops and 35ms away, the secondary 7 hops and 40ms away. I'm glad I got this solved. I really wish that when I was using the Google resolvers that Postfix would have been logging some kind of errors. If it had, I'd have known I had a real problem much sooner. The total lack of log entries for ~3 months is what finally jolted me to look into this. This is a sad state of affairs. So the question at this point is, why didn't Postfix log any errors when NXDOMAIN domain was returned, but did log errors when SERVFAIL is returned? -- Stan
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Mikael Bak put forth on 1/22/2010 7:50 AM: > Stan Hoeppner wrote: >> >> 1. Spamhaus has banned Google Public DNS resolver queries. > > Stan, > Do you have a good enough reason to not run your own name resolver on > your front MX machine? > > IMO relying on third parties for DNS on an MX is bad design. Due to this fiasco I'm already looking into it. I'd never really considered it an issue until now since it's such a light duty box. Not sure if I have enough memory on the box right now to run a caching resolver. I may need to grab a stick or two. It wouldn't be an issue except for the fact I recently added a bunch of daemons to this box so I could decommission a _really old_ machine (dual P166) that housed the mail store and file shares. That increased the memory footprint quite a bit. Suggestions for a lightweight local resolver daemon on Debian Lenny are welcome. I've never actually used bind before and I've never been a dns admin. I have a vague hazy memory of reading grumblings that bind may be a bit too "heavy" for using as a local machine resolver. -- Stan
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Kenneth Marshall put forth on 1/22/2010 8:39 AM: > pdns-recursor 3.1.7.2 is easy to configure/use and has a tuneable > resource footprint. Got her installed, configured, up and running. Let's see if this improves this spamhaus situation, and a handful a day of other dns related errors I've been getting during mail transactions. Those other errors may be normal, maybe not. This resolver should help me figure that out. I limited the cache to 65536 entries to start with to keep the ram footprint low. That should be plenty for mail, maybe enough to serve my workstation as well. With it nearly empty at this point pdns_recursor is only occupying 1628 Bytes RES and 4016 VIRT. So far so good in the low resource consumption department. Thanks for the suggestion Ken. -- Stan
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Noel Jones put forth on 1/22/2010 10:00 AM: > Nothing is logged because the DNS server gives an authoritive "does not > exist" answer. That's not an error, it is the expected response when a > client is not listed in an RBL. Hi Noel, I was not venting at Postfix, or Wietse, or any of the devs for that matter, as much as I was venting at the situation. Vietse, Victor, my apologies if it seemed I was venting at you. I was not. My venting should be aimed at Spamhaus. What they've done here is the opposite of transparency. In the case of Google DNS, Spamhaus has pulled something a bit underhanded in my estimation. They don't want people using Google DNS to query Spamhaus zones. That's fine. I have no problem with that. But the way in which they have blocked access creates a silent discard on mail servers using Google DNS, or at least Postfix (I can't speak for other MTAs in this regard). What they should have done is reply with a code that actually generates a visible log error, so an admin, such as myself, can actually see that something is wrong. Instead, all I got from my logs was silence. Multiple months of that deafening silence finally prompted my action as I knew there had to be something wrong. My A/S special sauce is good, but it's not so darn good that I wouldn't at least get one zen lookup in a few months. Thankfully it's good enough that even without any dnsbls I've only been averaging about 1 spam/day in the inbox. Getting zen lookups working again may not help much, but at least I'll get one more shot at killing the junk before letting it through. Anyway, I've got my own resolver up now on my Postfix MX. It appears to be working: greer:/# host 2.0.0.127.zen.spamhaus.org 2.0.0.127.zen.spamhaus.org A 127.0.0.10 2.0.0.127.zen.spamhaus.org A 127.0.0.2 2.0.0.127.zen.spamhaus.org A 127.0.0.4 -- Stan
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Mark Goodge put forth on 1/22/2010 11:07 AM: > It's not the fault of > Spamhaus, Google or Postfix if people don't RTFM. I'll give you that. I'd been using zen for years, and sbl-xbl for years before that. When I changed my resolvers to Google from my current provider's (for performance reasons, and not just my MX), I didn't go to spamhaus.org to check and make sure it was ok to do so. It never dawned on me that there would be a problem. I guess because I'm not a dns monkey (not a racial slur, think training monkeys) it just didn't occur to me that there would be a problem. The most interesting part about this, actually, is that when I switched my resolvers back today, I found Google was apparently blocking them also, Centurylink's dsl customer resolvers. This happened within the past 3 months. I don't know what the reason is, but I doubt it's based on query volume given that these resolvers serve residential and small business dsl customers. They were working fine before I switched to Google resolvers. I think it's working again now, though I'll have to wait and see, given my mail flow and the fact that zen and postgrey only get table scraps, and not many at that. ;) -- Stan
Re: Putting $data_directory on a RAM filesystem
Stefan Foerster put forth on 1/23/2010 11:08 AM: > In case of severe server "overload", with postscreen(8) complaining > about lookup and update times around 400ms almost every mail, is it > (reasonably) safe as a last desperate measure to put $data_directory, > or at least the file referenced by $postscreen_cache_map, on a ramdisk > (e.g. "tmpfs" with Linux)? > > I know about RAM not being persistent across reboots, and I understand > what happens if the $postscreen_cache_map (or all the contents in > $data_directory) are lost. If the problem is due to an I/O bottleneck, I'd recommend going SSD instead of RAM disk. Get this Crucial 64GB SATA2 unit and put both the postfix spool and postscreen db files on it: http://www.newegg.com/Product/Product.aspx?Item=N82E16820148318 Or, like Wietse said, first identify the actual cause of the problem. Then if it's I/O related, get an SSD drive. It's a relatively cheap path to massive random I/O throughput. -- Stan
Re: Postfix as a filtering/relay box
Javier Fox put forth on 1/27/2010 7:57 PM: > Greetings, > > I've inherited a rather kludgy email system consisting of an overpriced, > underpowered spam filtering appliance which I would very much like to > replace with a simple *nix box running Postfix and some manner of spam > filtering software (ie spamassassin). > > I would like to be able to keep the present scheme of how mail is passed > around if possible, but I'm not entirely certain where to begin with > respect to Postfix. Currently, our mail flow looks like this: > > -MX for domain points to the spam filtering appliance > -Appliance handles user verification (via ldap), rejection, quarantine, etc > -'Clean' mail handed off to MTA for final delivery > > The slightly funky part is that there are a number of destination MTA > servers, each servicing a subset of domains and mailboxes. A > configuration setting on the Appliance maps each domain to its > destination MTA server. > > Is it possible to set up Postfix as a drop-in replacement for this > appliance? Can I tell it "here are the domains to accept mail for, here > is an LDAP full of mailboxes to accept, and here is a hash/sqldb mapping > each domain to its destination MTA" > > Any advice or pointing in the right direction would be greatly > appreciated, as I'm really not sure how this all falls under the Postfix > definitions of canonical, virtual, relay, etc. Not only is it possible, this architecture is pretty widely deployed by many Postfix users. Unfortunately I don't have an exact "how to" for your scenario. You _will_ have a learning curve here. This won't be a simple drop in replacement for the anti spam box with the GUI front end. You'll be editing text configuration files with vi, and the bulk, if not all, of your administration of this box will be via telnet/ssh and a shell such as bash. If this sounds ok then read on. Start here: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall http://www.postfix.org/CONTENT_INSPECTION_README.html http://www.postfix.org/SMTPD_PROXY_README.html http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions http://www.postfix.org/DATABASE_README.html http://www.postfix.org/LDAP_README.html http://www.postfix.org/transport.5.html -- Stan
Re: Postfix as a filtering/relay box
Stan Hoeppner put forth on 1/27/2010 9:47 PM: > http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall > http://www.postfix.org/CONTENT_INSPECTION_README.html > http://www.postfix.org/SMTPD_PROXY_README.html > http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions > http://www.postfix.org/DATABASE_README.html > http://www.postfix.org/LDAP_README.html > http://www.postfix.org/transport.5.html Javier, I forgot to ask. What is your current message load, inbound emails/hour or emails/day, gross, including spam? What is the hardware configuration of the box you plan to deploy? Mainly looking for CPU/Disk (RAID?) specs as I'm sure you'll have at least 2-4GB RAM in it at current RAM prices. Also, what Linux distro? -- Stan
Re: allowing outside users access to mailman lists
Jeff Weinberger put forth on 1/28/2010 4:18 PM: > You've made it clear I'm posting the wrong thing - but I don't know > what the "right" thing is Sorry to but in Wietse. Jeff, paste all of postconf -n output and obfuscate any sensitive information in it such as hostnames or IP addresses that you don't want made public here. Wietse may not know what the "right" thing is until he sees all of postconf -n. There are interdependencies between various settings and often problems can't be identified without seeing the big picture. If you read the list welcome message and posting instructions you'd see that "postconf -n" output is a standard requirement here for receiving help. You are not being asked to provide anything beyond what everyone else is asked to provide. If you want assistance, we need to see the data. It's that's simple. Cooperate and everything will work out fine, you'll have a solution. Best regards. -- Stan
smtpd processes congregating at the pub
Based on purely visual non-scientific observation (top), it seems my smtpd processes on my MX hang around much longer in (Debian) 2.5.5 than they did in (Debian) 2.3.8. In 2.3.8 Master seemed to build them and tear them down very quickly after the transaction was complete. An smtpd process' lifespan was usually 10 seconds or less on my 2.3.8. In 2.5.5 smtpd's seem to hang around for up to 30 secs to a minute. Local shows very speedy delivery. Is this "long" smtpd process lifespan normal for 2.5.5 or did I do something screwy/wrong in my config? relay=local, delay=2.2, delays=2.2/0/0/0.01, dsn=2.0.0, status=sent relay=local, delay=0.32, delays=0.29/0.02/0/0, dsn=2.0.0, status=sent relay=local, delay=0.77, delays=0.75/0.03/0/0, dsn=2.0.0, status=sent relay=local, delay=0.26, delays=0.25/0/0/0.01, dsn=2.0.0, status=sent relay=local, delay=0.64, delays=0.62/0.03/0/0, dsn=2.0.0, status=sent relay=local, delay=0.26, delays=0.25/0/0/0, dsn=2.0.0, status=sent -- Stan
Re: smtpd processes congregating at the pub
Stan Hoeppner put forth on 1/29/2010 12:27 AM: > Based on purely visual non-scientific observation (top), it seems my smtpd > processes on my MX hang around much longer in (Debian) 2.5.5 than they did in > (Debian) 2.3.8. In 2.3.8 Master seemed to build them and tear them down very > quickly after the transaction was complete. An smtpd process' lifespan was > usually 10 seconds or less on my 2.3.8. In 2.5.5 smtpd's seem to hang around > for up to 30 secs to a minute. > > Local shows very speedy delivery. Is this "long" smtpd process lifespan > normal > for 2.5.5 or did I do something screwy/wrong in my config? > > relay=local, delay=2.2, delays=2.2/0/0/0.01, dsn=2.0.0, status=sent > relay=local, delay=0.32, delays=0.29/0.02/0/0, dsn=2.0.0, status=sent > relay=local, delay=0.77, delays=0.75/0.03/0/0, dsn=2.0.0, status=sent > relay=local, delay=0.26, delays=0.25/0/0/0.01, dsn=2.0.0, status=sent > relay=local, delay=0.64, delays=0.62/0.03/0/0, dsn=2.0.0, status=sent > relay=local, delay=0.26, delays=0.25/0/0/0, dsn=2.0.0, status=sent I think I found it: max_idle = x The default is 100 on my system. I changed it to 10 and that seems to have had an effect. Did this setting exist in 2.3.8? I didn't see a version note next to max_idle in my 2.5.5 man smtpd. If so, was the default something insanely low like 1, or 0? Like I said, smtpd's seemed to come and go in a hurry on 2.3.8. -- Stan
VRFY defaults to on--why?
Hay Wietse, Someone was wondering on spam-l why Postfix defaults smtpd VRFY to ON instead of OFF. Their theory being that the default of ON makes it easier for spammers to harvest addresses. Most people shut if off (including me). Then spammers go to RCPT TO checking, so IMO it makes little difference. Just wanted your position on this so I can post an official response to spam-l. I don't want Postfix (or you) getting any kind of ill-deserved reputation due to VRFY defaulting to on. Minor issue, silly yes, but apparently important to some. So, what do I tell them? Has this already been answered long ago? Link? Thanks. -- Stan
Re: smtpd processes congregating at the pub
Wietse Venema put forth on 1/29/2010 6:15 AM: > Stan Hoeppner: >> Based on purely visual non-scientific observation (top), it seems my smtpd >> processes on my MX hang around much longer in (Debian) 2.5.5 than they did in >> (Debian) 2.3.8. In 2.3.8 Master seemed to build them and tear them down very > > Perhaps Debian changed this: > http://www.postfix.org/postconf.5.html#max_idle > > The Postfix default is 100s. Yes, I confirmed this on my system. > I don't really see why anyone would shorten this - that's a waste > of CPU cycles. In particular, stopping Postfix daemons after 10s > means that people don't have a clue about what they are doing. > The fact that it's now increased to 30s confirms my suspicion. Think of a lightly loaded (smtp connects/min) vanity domain server that functions as a Postfix MX with local delivery, a Dovecot IMAP, a Lighty+Roundcube, a Samba server, and a dns resolver serving local requests and one remote workstation. The system is also used interactively (via SSH/BASH) for a number of things including an occasional kernel compile. The machine only has 384MB of RAM. My smtp load is low enough that having an smtpd process or two hanging around for 100 seconds just wastes 13-18MB per smtpd of memory for 80-90 of those 100 seconds. This system regularly goes 5 minutes or more between smtp connects. Sometimes two come in simultaneously, and I end up with two smtpd processes hanging around for 100 seconds, eating over 30MB RAM with no benefit. Thus, for me, it makes more sense to have the smtpd's exit as soon as possible to free up memory that can be (better) used for something else. Yes, I guess I'm a maniac. ;) In this scenario, with very infrequent smtpd reuse, do you still think I should let them idle for 100 seconds, or at all? From my perspective, that 18-30MB+ can often be better utilized during that time. -- Stan
Re: smtpd processes congregating at the pub
Wietse Venema put forth on 1/30/2010 9:03 AM: > Allow me to present a tutorial on Postfix and operating system basics. Thank you Wietse. I'm always eager to learn. :) > Postfix reuses processes for the same reasons that Apache does; > however, Apache always runs a fixed minimum amount of daemons, > whereas Postfix will dynamically shrink to zero smtpd processes > over time. Possibly not the best reference example, as I switched to Lighty mainly due to the Apache behavior you describe, but also due to Apache resource hogging in general. But I understand your point. It's better to keep one or two processes resident to service the next inbound requests than to constantly tear down and then rebuild processes, which causes significant overhead and performance issues on busy systems. > Therefore, people who believe that Postfix processes should not be > running in the absence of client requests, should also terminate > their Apache processes until a connection arrives. No-one does that. Wouldn't that really depend on the purpose of the server? How about a web admin daemon running on a small network device? I almost do this with Lighty currently. I have a single daemon instance that handles all requests, max processes=1. It's a very lightly loaded server, and a single instance is more than enough. In fact, given the load, I might possibly look into running Lighty from inetd, if possible, as I do Samba. > If people believe that each smtpd process uses 15MB of RAM, and > that two smtpd processes use 30MB of RAM, then that would have been > correct had Postfix been running on MS-DOS. > > First, the physical memory footprint of a process (called resident > memory size) is smaller than the virtual memory footprint (which > comprises all addressable memory including the executable, libraries, > data, heap and stack). With FreeBSD 8.0 I see an smtpd VSZ/RSS of > 6.9MB/4.8MB; with Fedora Core 11, 4.2MB/1.8MB; and with FreeBSD > 4.1 it's 1.8MB/1.4MB. Ten years of system library bloat. Debian 5.0.3, kernel 2.6.31 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 29242 postfix 20 0 22408 18m 2268 S0 4.9 0:00.58 smtpd 29251 postfix 20 0 17264 13m 2208 S0 3.6 0:00.48 smtpd > Second, when multiple processes execute the same executable file > and libraries, those processes will share a single memory copy of > the code and constants of that executable file and libraries. > Therefore, a large portion of their resident memory sizes will > actually map onto the same physical memory pages. 15+15 != 30. I was of the understanding that top's SHR column described memory shareable with other processes. In the real example above from earlier today, it would seem that my two smtpd processes can only share ~2.2MB of code, data structures, etc. man top: t: SHR -- Shared Mem size (kb) The amount of shared memory used by a task. It simply reflects memory that could be potentially shared with other processes. Am I missing something, or reading my top output incorrectly? > Third, some code uses mmap() to allocate memory that is mapped from > a file. This adds to the virtual memory footprint of each process, > but of course only the pages that are actually accessed will add > to the resident memory size. In the case of Postfix, this mechanism > is used by Berkeley DB to allocate a 16MB shared-memory read buffer. Is this 16MB buffer also used for hash and/or cidr tables, and is this shareable? AFAIK I don't use Berkeley DB tables, only hash (small,few) and cidr (very large, a handful). > There are some other tricks that allow for further savings (such > as copy-on-write, which allows sharing of a memory page until a > process attempts to write to it) but in the case of Postfix, those > savings will be modest. I must be screwing something up somewhere then. According to my top output, I'm only sharing ~2.2MB between smtpd processes, yet I've seen them occupy anywhere from 11-18MB RES. If the top output is correct, there is a huge amount of additional sharing that "should" be occurring, no? Debian runs Postfix in a chroot by default. I know very little about chroot environments. Could this have something to do with the tiny amount of shared memory between the smtpds? Thanks for taking interest in this Wietse. I'm sure I've probably done something screwy that is easily fixable, and will get that shared memory count up where it should be. -- Stan
Re: smtpd processes congregating at the pub
Wietse Venema put forth on 1/30/2010 7:14 PM:
> Stan Hoeppner:
>> AFAIK I don't use Berkeley DB tables, only hash (small,few) and cidr
>> (very large, a handful).
>
> hash (and btree) == Berkeley DB.
Ahh, good to know. I'd thought only btree used Berkeley DB and that hash tables
used something else.
> If you have big CIDR tables, you can save lots of memory by using
> proxy:cidr: instead of cidr: (and running "postfix reload").
> Effectively, this turns all that private memory into something that
> can be shared via the proxy: protocol.
I implemented proxymap but it doesn't appear to have changed the memory
footprint of smtpd much at all, if any. I reloaded once, and restarted once
just in case.
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
4554 postfix 20 0 20828 17m 2268 S0 4.5 0:00.46 smtpd
4560 postfix 20 0 20036 16m 2268 S0 4.3 0:00.47 smtpd
4555 postfix 20 0 6812 3056 1416 S0 0.8 0:00.10 proxymap
> The current CIDR implementation is optimized to make it easy to
> verify for correctness, and is optimized for speed when used with
> limited lists of netblocks (mynetworks, unassigned address blocks,
> reserved address blocks, etc.).
Understood.
> If you want to list large portions of Internet address space such
> as entire countries the current implementation starts burning CPU
> time (it examines all CIDR patterns in order; with a bit of extra
> up-front work during initialization, address lookups could skip
> over a lot of patterns, but the implementation would of course be
> harder to verify for correctness), and it wastes 24 bytes per CIDR
> rule when Postfix is compiled with IPv6 support (this roughly
> doubles the amount memory that is used by CIDR tables).
I don't really notice much CPU burn on any postfix processes with these largish
CIDRs, never have. I've got 12,212 CIDRs in 3 files, 11,148 of them in just the
"countries" file alone. After implementing proxymap, I'm not seeing much
reduction in smtpd RES size, maybe 1MB if that. SHR is almost identical to
before. If it's not the big tables bloating smtpd, I wonder what is? Or, have
I not implemented proxymap correctly? Following are my postconf -n and main.cf
relevant parts.
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
inet_interfaces = all
message_size_limit = 1024
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = hardwarefreak.com
myhostname = greer.hardwarefreak.com
mynetworks = 192.168.100.0/24
myorigin = hardwarefreak.com
parent_domain_matches_subdomains = debug_peer_list smtpd_access_maps
proxy_interfaces = 65.41.216.221
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
$sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
proxy:${cidr}/countries proxy:${cidr}/spammer proxy:${cidr}/misc-spam-srcs
readme_directory = /usr/share/doc/postfix
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
relay_domains =
smtpd_banner = $myhostname ESMTP Postfix
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks
reject_unauth_destination check_recipient_access
hash:/etc/postfix/whitelist check_sender_access hash:/etc/postfix/whitelist
check_client_access hash:/etc/postfix/whitelist check_client_access
hash:/etc/postfix/blacklist check_client_access
regexp:/etc/postfix/fqrdns.regexp check_client_access
pcre:/etc/postfix/ptr-tld.pcre check_client_access proxy:${cidr}/countries
check_client_access proxy:${cidr}/spammer check_client_access
proxy:${cidr}/misc-spam-srcsreject_unknown_reverse_client_hostname
reject_non_fqdn_sender reject_non_fqdn_helo_hostname
reject_invalid_helo_hostnamereject_unknown_helo_hostname
reject_unlisted_recipient reject_rbl_client zen.spamhaus.org
check_policy_service inet:127.0.0.1:6
strict_rfc821_envelopes = yes
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/main.cf snippet
cidr=cidr:/etc/postfix/cidr_files
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
$sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
proxy:${cidr}/countries proxy:${cidr}/spammer proxy:${cidr}/misc-spam-srcs
check_client_access proxy:${cidr}/countries
check_client_access proxy:${cidr}/spammer
check_client_access proxy:${cidr}/misc-spam-srcs
--
Stan
Re: smtpd processes congregating at the pub
Sorry for top posting. Forgot to add something earlier: Proxymap seems to be
exiting on my system immediately after servicing requests. It does not seem to
be obeying $max_use or $max_idle which are both set to 100. It did this even
before I added cidr lists to proxymap a few hours ago. Before that, afaik, it
was only being called for local alias verification, and it exited immediately in
that case as well.
--
Stan
Stan Hoeppner put forth on 1/30/2010 11:13 PM:
> Wietse Venema put forth on 1/30/2010 7:14 PM:
>> Stan Hoeppner:
>>> AFAIK I don't use Berkeley DB tables, only hash (small,few) and cidr
>>> (very large, a handful).
>>
>> hash (and btree) == Berkeley DB.
>
> Ahh, good to know. I'd thought only btree used Berkeley DB and that hash
> tables
> used something else.
>
>> If you have big CIDR tables, you can save lots of memory by using
>> proxy:cidr: instead of cidr: (and running "postfix reload").
>> Effectively, this turns all that private memory into something that
>> can be shared via the proxy: protocol.
>
> I implemented proxymap but it doesn't appear to have changed the memory
> footprint of smtpd much at all, if any. I reloaded once, and restarted once
> just in case.
>
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 4554 postfix 20 0 20828 17m 2268 S0 4.5 0:00.46 smtpd
> 4560 postfix 20 0 20036 16m 2268 S0 4.3 0:00.47 smtpd
> 4555 postfix 20 0 6812 3056 1416 S0 0.8 0:00.10 proxymap
>
>> The current CIDR implementation is optimized to make it easy to
>> verify for correctness, and is optimized for speed when used with
>> limited lists of netblocks (mynetworks, unassigned address blocks,
>> reserved address blocks, etc.).
>
> Understood.
>
>> If you want to list large portions of Internet address space such
>> as entire countries the current implementation starts burning CPU
>> time (it examines all CIDR patterns in order; with a bit of extra
>> up-front work during initialization, address lookups could skip
>> over a lot of patterns, but the implementation would of course be
>> harder to verify for correctness), and it wastes 24 bytes per CIDR
>> rule when Postfix is compiled with IPv6 support (this roughly
>> doubles the amount memory that is used by CIDR tables).
>
> I don't really notice much CPU burn on any postfix processes with these
> largish
> CIDRs, never have. I've got 12,212 CIDRs in 3 files, 11,148 of them in just
> the
> "countries" file alone. After implementing proxymap, I'm not seeing much
> reduction in smtpd RES size, maybe 1MB if that. SHR is almost identical to
> before. If it's not the big tables bloating smtpd, I wonder what is? Or,
> have
> I not implemented proxymap correctly? Following are my postconf -n and
> main.cf
> relevant parts.
>
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> disable_vrfy_command = yes
> header_checks = pcre:/etc/postfix/header_checks
> inet_interfaces = all
> message_size_limit = 1024
> mime_header_checks = pcre:/etc/postfix/mime_header_checks
> mydestination = hardwarefreak.com
> myhostname = greer.hardwarefreak.com
> mynetworks = 192.168.100.0/24
> myorigin = hardwarefreak.com
> parent_domain_matches_subdomains = debug_peer_list smtpd_access_maps
> proxy_interfaces = 65.41.216.221
> proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
> $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
> $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
> $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
> $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
> proxy:${cidr}/countries proxy:${cidr}/spammer proxy:${cidr}/misc-spam-srcs
> readme_directory = /usr/share/doc/postfix
> recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
> relay_domains =
> smtpd_banner = $myhostname ESMTP Postfix
> smtpd_helo_required = yes
> smtpd_recipient_restrictions = permit_mynetworks
> reject_unauth_destination check_recipient_access
> hash:/etc/postfix/whitelist check_sender_access hash:/etc/postfix/whitelist
> check_client_access hash:/etc/postfix/whitelist check_client_access
> hash:/etc/postfix/blacklist check_client_access
> regexp:/etc/postfix/fqrdns.regexp check_client_access
> pcre:/etc/postfix/ptr-tld.pcre check_client_access proxy:${cidr}/countries
> check_client_access proxy:${cidr}/spammer check_client_access
> proxy:${cidr}/misc-spam-srcsreject_unknown_reverse_client_hostname
&
Re: create new email address in postfix
dd1313 put forth on 1/31/2010 2:44 AM: > > could you point me to that part of the docs that refer to that.Actually I > know not what to do next. > I have logged in as root on ubuntu, what is next please http://www.howtogeek.com/howto/ubuntu/add-a-user-on-ubuntu-server/ -- Stan
Re: smtpd processes congregating at the pub
Stan Hoeppner put forth on 1/31/2010 12:04 AM: > Sorry for top posting. Forgot to add something earlier: Proxymap seems to be > exiting on my system immediately after servicing requests. It does not seem > to > be obeying $max_use or $max_idle which are both set to 100. It did this even > before I added cidr lists to proxymap a few hours ago. Before that, afaik, it > was only being called for local alias verification, and it exited immediately > in > that case as well. Making a little more progress on this, slowly. I'd forgotten that I have a regexp table that's rather large, containing 1626 expressions. I added it to proxymap, and this action dropped the size of my smtpd processes dramatically, by about a factor of 5. Apparently, even though this regexp table has only 1626 lines, it requires far more memory than my big 'countries' cidr table which has 11148 lines. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 14411 postfix 20 0 20276 16m 1480 S8 4.3 0:00.51 proxymap 14410 postfix 20 0 6704 3368 2208 S0 0.9 0:00.04 smtpd This is making good progress. Seeing the smtpd's memory footprint drop so dramatically is fantastic. However, I'm still curious as to why proxymap doesn't appear to be honoring $max_idle or $max_use. Maybe my understanding of $max_use is not correct? It's currently set to 100, the default. Watching top while sending a test message through, I see proxymap launch but then exit within 5 seconds, while smtpd honors max_idle. Is there some other setting I need to change to keep proxymap around longer? -- Stan
Re: VRFY defaults to on--why?
Jacqui Caren-home put forth on 1/31/2010 12:47 PM: > I recommend joining the spam-l list and joining the discussion there. I recommend against this. The topic is dead there now. One poster there questioned why Wietse enabled it by default. I merely asked here so I could post an official answer to spam-l. In hind sight, maybe I should have emailed Wietse directly. My apologies if I've started a useless debate here. This topic has been beaten to death in many fora over the years. No need to rehash it again really. -- Stan
Re: smtpd processes congregating at the pub
Wietse Venema put forth on 1/31/2010 10:38 AM: > Stan Hoeppner: >> This is making good progress. Seeing the smtpd's memory footprint >> drop so dramatically is fantastic. However, I'm still curious as >> to why proxymap doesn't appear to be honoring $max_idle or $max_use. >> Maybe my understanding of $max_use is not correct? It's currently >> set to 100, the default. Watching top while sending a test message >> through, I see proxymap launch but then exit within 5 seconds, >> while smtpd honors max_idle. Is there some other setting I need >> to change to keep proxymap around longer? > > Short answer (workaround for low-traffic sites): set ipc_idle=$max_idle > to approximate the expected behavior. This keeps the smtpd-to-proxymap > connection open for as long as smtpd runs. Then, proxymap won't > terminate before its clients terminate. Wietse, thank you for the very thorough and thoughtful response. For a few reasons, including the fact I don't trust myself working with source in this case, and that I'd rather not throw monkey wrenches into my distro's package management, I'm going to go with the short answer workaround above. All factors being taken into account, I think it best fits my needs, skills, and usage profile. > Better: apply the long-term solution, in the form of the patch below. > This undoes the max_idle override (a workaround that I introduced > with Postfix 2.3). I already introduced the better solution with > Postfix 2.4 while solving a different problem. I'm not sure if I fully understand this. I'm using 2.5.5, so shouldn't I already have the 2.4 solution mentioned above? I must not be reading this correctly. > Long answer: in ancient times, all Postfix daemons except qmgr > implemented the well-known max_idle=100s and max_use=100, as well > as the lesser-known ipc_idle=100s (see "short answer" for the effect > of that parameter). > > While this worked fine for single-client servers such as smtpd, it > was not so great for multi-client servers such as proxymap or > trivial-rewrite. This problem was known, and the idea was that it > would be solved over time. > > Theoretically, smtpd could run for up to $max_idle * $max_use = 3 > hours, while proxymap and trivial-rewrite could run for up to > $max_idle * $max_use * $max_use = 12 days on low-traffic systems > (one SMTP client every 100s, or a little under 900 SMTP clients a > day), and it would run forever on systems with a steady mail flow. > > This was a problem. The point of max_use is to limit the impact of > bugs such as memory or file handle leaks, by retiring a process > after doing a limited amount of work. I can test Postfix itself > with tools such as Purify and Valgrind, but I can't do those tests > with every version of everyone's system libraries. This is a very smart design philosophy. Just one more reason I feel privileged to use Postfix. > If a proxymap or trivial-rewrite server can run for 11 days even > on systems with a minuscule load, then max_use isn't working as > intended. > > The main cause is that the proxymap etc. clients reuse a connection > to improve efficiency. Therefore, the proxymap etc. server politely > waits until all its clients have disconnected before checking the > max_use counter. While this politeness thing can't be changed > easily, it is relatively easy to play with the proxymap etc. server's > max_idle value, and with the smtpd etc. ipc_ttl value. > > Postfix 2.3 reduced the proxymap etc. max_idle to a fixed 1s value > to make those processes go away sooner when idle. I think that > this was a mistake, because it makes processes terminate too soon, > and thereby worsens the low-traffic behavior. Instead, we should > speed up the proxymap etc. server's max_use counter. > Postfix 2.4 reduced ipc_ttl to 5s. This was done for a different > purpose: to allow proxymap etc. clients to switch to the least-loaded > proxymap etc. server. But, I think that this was also the right way > to deal with long-lived proxymap etc. processes, because it speeds > up the proxymap etc. max_use counter. Absolutely fascinating background information Wietse. Thank you for sharing this. It's always nice to learn how/why some things work "under the hood"; things that often can't easily be found in any official documentation. -- Stan
Re: smtpd processes congregating at the pub
Wietse Venema put forth on 1/31/2010 7:34 PM: > Stan Hoeppner: >>> Better: apply the long-term solution, in the form of the patch below. >>> This undoes the max_idle override (a workaround that I introduced >>> with Postfix 2.3). I already introduced the better solution with >>> Postfix 2.4 while solving a different problem. >> >> I'm not sure if I fully understand this. I'm using 2.5.5, so shouldn't I >> already have the 2.4 solution mentioned above? I must not be reading this >> correctly. > > The patch undoes the Postfix 2.3 change that is responsible for > the shorter-than-expected proxymap lifetimes that you observed > on low-traffic systems. > > With that change backed out, the reduced ipc_idle change from > Postfix 2.4 will finally get a chance to fix the excessive lifetime > of proxymap and trivial-rewrite processes on high-traffic systems. So, if I understand correctly, these changes made in 2.3 and 2.4 were to get more desirable behavior from proxymap and trivial-rewrite on high traffic systems, and this caused this (very minor) problem on low traffic systems? The patch resolves the low traffic issue, basically reverting to the older code used before said 2.3 changes? And these changes have, through 2.7, given the desired behavior on high-traffic systems? Or no? Your statement "will finally get a chance to..." is future tense. Does this mean the desired behavior for high-traffic systems has not been seen to date? I apologize if this seems a stupid question. The future tense in your statement confuses me. If that _is_ what you mean, future tense, does this mean I have inadvertently played a tiny role in helping you identify a long standing problem/issue? ;) -- Stan
Re: smtpd processes congregating at the pub
Noel Jones put forth on 1/29/2010 8:44 AM: > On 1/29/2010 1:37 AM, Stan Hoeppner wrote: >>> Local shows very speedy delivery. Is this "long" smtpd process >>> lifespan normal >>> for 2.5.5 or did I do something screwy/wrong in my config? >>> >>> relay=local, delay=2.2, delays=2.2/0/0/0.01, dsn=2.0.0, status=sent >>> relay=local, delay=0.32, delays=0.29/0.02/0/0, dsn=2.0.0, status=sent >>> relay=local, delay=0.77, delays=0.75/0.03/0/0, dsn=2.0.0, status=sent >>> relay=local, delay=0.26, delays=0.25/0/0/0.01, dsn=2.0.0, status=sent >>> relay=local, delay=0.64, delays=0.62/0.03/0/0, dsn=2.0.0, status=sent >>> relay=local, delay=0.26, delays=0.25/0/0/0, dsn=2.0.0, status=sent > Nitpick: you talk about smtpd, then show log snips from smtp. But no > matter, they both honor max_idle and will behave in a similar manner. Maybe I could have worded that more clearly Noel. Those snippets are from postfix/local not smtp. smtp doesn't normally relay to local, afaik. ;) I included these snippets in an attempt to show that inbound delivery is very fast. Not understanding the smtpd process behavior at the time, wrt max_idle, I assume that fast delivery would equal smtpd exiting quickly. smtpd doesn't log delays afaict, so I included the local information instead. My apologies for the confusion. -- Stan
Re: suitable webmail
Carlos Williams put forth on 2/1/2010 10:04 AM: > I recommend and prefer Roundcube. > > http://roundcube.net/ +1 If you're going to offer webmail, you may as well offer IMAP folders instead of POP. JMHO. I'm an ex Squirrelmail user and switched to Roundcube, mainly for the nicer user interface. My Roundcube connects to Dovecot IMAP on the local machine. IIRC, when I logged in the first time it grabbed all the IMAP folders automatically. Back when I originally setup Squirrelmail years ago, I had to subscribe all the folders manually. I'm not sure if this is true of the most recent Squirrelmail though. Other than Roundcube, for a really nice modern AJAX interface, take a look at SOGo. The thing that really impresses me is the right click context menus like those available in Thunderbird or other GUI mail clients. I ended up going with Roundcube as I thought SOGo was a bit "heavy" for my needs. Give the demo a go and see what you think: http://www.scalableogo.org/english/tour/online_demo.html -- Stan
[OT] suitable webmail
Kay put forth on 2/1/2010 11:49 AM: > In my job (hosting company) I see boxes exploited via roundcube all the > time. Squirrelmail? Not one so far. Part of the reason is that > squirrelmail comes with RHEL, so it's kept up to date automatically, > while customers install their own roundcube and then don't maintain it. I think you're making some incorrect assumptions. Squirrelmail has had a pretty abysmal security track record of its own over the years. One reason for that is probably exactly what you're calling out Roundcube for here, which has nothing to do with the software, but the administration of the system. That said, you appear to think the world runs on Red Hat, and if Red Hat doesn't have a Roundcube package, admins will install from source or an external RPM that doesn't get updated by Red Hat's uptodate or whatever it's called. The world doesn't run on Red Hat, and many admins _do_ keep their Roundcube (and other) packages up to date. For instance, I do security updates on my Debian servers once a week. My Roundcube package is currently up to date, and it is a standard Debian package: [02:21:52][r...@greer]/$ aptitude show roundcube Package: roundcube New: yes State: installed Automatically installed: no Version: 0.2.2-1~bpo50+1 Priority: extra Section: web Maintainer: Debian Roundcube Maintainers Uncompressed Size: 94.2k Depends: roundcube-core (= 0.2.2-1~bpo50+1) Description: skinnable AJAX based webmail solution for IMAP servers - metapackage > That said, it's not the only webmail client (or any other web app) that > gets the install&neglect treatment, it's just the one most frequently > exploited. Do you have any empirical data showing that Roundcube is exploited more often today than Squirrelmail? Claims like this really need to be backed up. Data for only your data center doesn't count, the sample size is way too small. This is called "anecdotal" evidence, not empirical evidence. -- Stan
Re: [OT] suitable webmail
Charles Marcus put forth on 2/1/2010 4:17 PM: > On 2010-02-01 4:05 PM, Stan Hoeppner wrote: >> My Roundcube package is currently up to date, and it is a standard >> Debian package: >> >> [02:21:52][r...@greer]/$ aptitude show roundcube >> Package: roundcube >> New: yes >> State: installed >> Automatically installed: no >> Version: 0.2.2-1~bpo50+1 > > Eh? 0.3.1 is the current version, so how is 0.2.2 'up to date'? The current discussion relates to keeping security patches current. http://www.debian.org/security/ All security flaw related new code is back ported and stable versions patched. You seem to be of the mistaken impression that one must have the latest 'release version' of a software package to have the latest security patches. This is not true of any *nix distro or Windows for that matter. Heck, M$ is still sending out security patches via automatic updates to Windows 2000 machines (until June 10 apparently). If there is a security flaw identified in the version of Roundcube I'm running (or any package), at some point a patched version will be made available in the security repository. Automated or manual upgrades via apt or aptitude will pull down the patched package and install it. -- Stan
Re: [OT] suitable webmail
Ralf Hildebrandt put forth on 2/1/2010 4:31 PM: > That's probably some sort of twisted Debian humor .) I wish it was humor... Debian Stable always lags pretty seriously behind the cutting edge release versions of a lot of packages. Then again, from what I understand, so do RHEL, CentOS, SLES, and some others. This seems indicative of "Stable" or "Enterprise" releases. The "stability" vs "features" argument, I assume. When testing is pushed to stable (not sure of the target date), I'll end up with Roundcube 3.1 after upgrading. All of that said, I don't find I'm lacking any functionality with my current version of Roundcube. -- Stan
Re: relay help
Wade Smart put forth on 2/1/2010 7:43 PM: > Right now I just sent from my mail client (thunderbird) but I would > like to be able to send back through postfix to keep a record of all > sent mails. That's what your Sent Items folder is for. You need to keep in mind that by default Postfix won't log the mail transactions in a way easily identifiable by you, except that you sent a message to u...@blah.com, the date and time. The entire messages aren't logged, just the transaction data, and the only way to correlate with Thunderbird will be via date/time stamps. I think you're going to a lot of trouble for zero gain. Even if you get this working, the resulting log files won't meet your needs. Did I mention log rotation? That's another wrench in the spokes, though it won't really matter since you can't discern the log info anyway. There are very few legitimate cases for running a full blown MTA such as Postfix on a laptop. Yours does not appear to be one of them. -- Stan
Re: Say to Postfix which email need to be delivered locally based on the full email address and not just based on the local domain
Michele Carandente put forth on 2/2/2010 3:57 AM: > message_size_limit = 3072 Unrelated to your question, but... You say this machine is behind a dial up line? Ouch! You may want to seriously consider changing this to something more sane like 262144. With a 56K modem averaging a real 45 Kb/s, it will take 47 seconds to transmit a single 256KB (262144 bytes) email. For 100 such messages it will take 78 minutes. If you allow 1MB (1048576 byte) messages, multiply transmission time by 4, which would be just over 5 hours for 100 messages of 1MB each. -- Stan
Re: Whitelist: ~user/.postfix_whitelist; chmod 600 .postfix_whitelist?
Radio Tron put forth on 2/3/2010 8:22 AM: > 3. How do I handle bounced mail and postmaster.. create a white-list file for > postmaster and put a rule saying PASS all.. will that create a loophole where > scumbags can spoof the FROM: field??? The scumbags always spoof the FROM: field. You can whitelist the postmaster address but still reject stuff destined to it containing postmas...@your.domain. Should be at least a couple methods to do this. -- Stan
Re: postfix 2.7 release date
DUBOURG Kevin put forth on 2/8/2010 4:23 AM: > On debian repository 2.5.5-1.1 ... Snif ... You're looking in the Lenny/Stable repo. Debian never adds new software revs into Stable TTBOMK. Lenny was released 14 Feb 09, one year ago. If you want Postfix 2.6.5 as a Deb package, you'll have to go to Squeeze, wait for Squeeze to become Stable, wait for a backport, or go the RPM-DEB route. If you want newer than 2.6.5 you'll have to go the RPM-DEB route or install from source. -- Stan
Re: postfix 2.7 release date
Jerry put forth on 2/8/2010 5:13 AM: > Wow, I was not aware the debian had actually progressed that far. Debian jumped from Postfix 2.3.8 on Etch to 2.5.5 when Lenny was flipped to Stable. Looong release cycles tend to produce these miracle "rev leaps" on occasion. On the flip side, more often, users have to wait 2 years for needed functionality. Depends on where an upstream rev is at when it enters Debian Un-stable and how much progress the upstream makes after that point. If Squeeze is flipped to Stable within 6 months, the Postfix package will be 2.6.5, not far at all behind upstream, considering Postfix 2.7 isn't finalized yet. Many people have been pushing Debian towards more frequent releases. The problem is the gargantuan number of architectures Debian supports. That equals a ton of general and bug testing, as they release all archs simultaneously. If one has a problem and is lagging behind, all must wait for release. Debian Stable has its problems, but overall, I've been more than happy with it for the past 10 years. -- Stan
Re: [OT] suitable webmail
K bharathan put forth on 2/2/2010 10:49 AM: > thanks for all > > On Tue, Feb 2, 2010 at 6:05 PM, Carlos Williams wrote: > >> On Tue, Feb 2, 2010 at 8:36 AM, Charles Marcus >> wrote: >>> On 2010-02-01 7:17 PM, Stan Hoeppner wrote: >>>> All of that said, I don't find I'm lacking any functionality with my >> current >>>> version of Roundcube. >>> >>> Then you haven't looked at it... the new features are really nice... I just installed 0.3.1 from Lenny backports, up from 0.2.2, and in brief testing I don't really notice any significant new features. I still don't see a "reply to list" option, which would be nice. What should I be looking for, and where? Sorry to drudge up an old OT topic. I'm cc'ing the roundcube list so we can move this discussion over there. -- Stan
Re: Error no. 2 postmulti
Wietse Venema put forth on 2/9/2010 8:54 AM: > Dhiraj Chatpar: >> Dear All, >> >> Please note that i am getting another error on ubuntu 9.10 machine with >> postfix 2.6.5 as below >> >> r...@smtp:/etc/postfix# postmulti -i postfix-1 -e enable >> r...@smtp:/etc/postfix# postmulti -i postfix-1 -p start >> /usr/lib/postfix/postfix-script: 373: /etc/postfix-1/postfix-script: not >> found >> postfix-1/postfix-script: starting the Postfix mail system > > Postfix 2.6, as released by me, installs the postfix-script file > in the /usr/libexec/postfix directory. > > You need to file a bug report with the DEBIAN maintainer. Debian runs Postfix in a chroot jail by default. I've never run multiple postfix instances under Debian, but I'm guessing these postmulti errors have something (maybe everything) to do with the jail setup. -- Stan
Re: relayhost - what smtp server can I use?
Jeff Lacki put forth on 2/9/2010 10:53 AM: > I have a situation with hosting.com, trying to setup > a friends postfix config. Since I knew nothing about > them I asked him to find out what their smtp server > was. They said that we cannot use it and gave us a link > to setup postfix, however they show no relayhost (smtp) > server in the config! > > My question is, who can I use as an smtp relayhost > if the local host doesnt have one? Typically in a hosting or colocation situation you send smtp directly to the recipient domains' MX'en. You don't typically use an smtp relay in this scenario. Unfortunately snowshoe spammers abuse both colos and hosting outfits, so the IP(s) you've been assigned my have a less than stellar mail reputation. This is the same reasons hosting companies don't want customers using their relays. They don't won't their relays ending up dnsbls. You didn't provide your IPs so I can't check them out. Run your IPs through this and see how many hits you get: http://www.mxtoolbox.com/blacklists.aspx If you only have a handful of hits, at places like the five-ten dnsbls, you should be fine sending direct smtp mail. If you find your IPs are listed in spamhaus, sorbs, or barracuda , you'll have a serious uphill battle getting your mail through. This is why people buying hosting or colo with the intention of sending mail need to do more than topical research into potential providers before handing them the plastic. For example, $4.95/month VPS service is probably not a good candidate for hosting a legit mail sending host because at that price spammers have probably already run the IP reputation of the provider into scorched earth territory. VPS in general, from a spam fighter perspective, is not a good place to host outbound mail. VPS services are nearly block-on-sight for many spam fighters. -- Stan
Re: suitable webmail
Thijssen put forth on 2/9/2010 4:19 AM: > - If they like flashy GUI bullshit like HTML-mail and WYSIWYG > formatted emails and spam and commerce, then don't use Squirrelmail. > - If they focuss on actual text content and plaintext emails (the way > it should be), then squirrelmail is your Number One choice, far > outweighing all others. > > It's rock stable and top-secure. Tell me about this "top-secure" aspect of Squirrelmail again. ;) Received: from mail.afranet.com (mail.afranet.com [80.75.0.13]) by greer.hardwarefreak.com (Postfix) with ESMTP id 1F0AC6C2B9 for ; Thu, 11 Feb 2010 07:02:04 -0600 (CST) ... Received: from 78.138.3.237 (SquirrelMail authenticated user test) by mail.afranet.com with HTTP; ... User-Agent: SquirrelMail/1.4.15 ... To: undisclosed-recipients:; ... :::YEAR 2010 E-MAIL AWARDS::: Dear Winner, ... CONTACT HIM WITH YOUR DETAILS, FILL Details BELOW; *** Your Full Name *** Your Address *** Your Country *** Your Phone number *** Your Age(Date of birth) *** Your Gender(Male or Female) *** Your present Occupation *** Your Micros ID ... I get phish and 419 from compromised Sqirrelmail servers at least once or twice a month. I've yet to receive one from a compromised Roundcube, Horde, or SOGo server. Now, in fairness to SM, this probably has as much to do with widespread implementation and poor administration as it does insecure code. It appears the phish sent from the SM server in the example above utilized a test account with a weak or non-existent password. Regarding Jose's comments about his web servers constantly being scanned for Roundcube directories, I see no one else reporting this. I run a Roundcube server and see nothing of the sort. Additionally, scans != compromise or high potential for compromise. I see thousands of scans and login attempts on my ssh and ftp ports monthly. Does that mean that Proftpd and sshd are automatically vulnerable? Because people are scanning them? You made a pretty weak argument against Roundcube with that example. -- Stan
Re: deliver problem ( Error: file_dotlock_create )
Frank Bonnet put forth on 2/12/2010 10:05 AM: > Hello all ( Postfix and Dovecot ) > > Trying to use deliver as mailbox_command with Postfix I get this > error each time an email is arriving > > deliver(): Error: file_dotlock_create(/var/mail/) > failed: Permission denied (euid=3003() egid=3010(smig) missing > +w perm: /var/mail) (set mail_privileged_group=mail) > > Doea this means I have to chmod 777 the /var/mail directory ? If you're using dovecot mbox format but are not going to use sieve etc, then just have Postfix local drop the mail. That's what I do. Works great. -- Stan
Re: suitable webmail
LuKreme put forth on 2/12/2010 10:08 AM: > On 12-Feb-2010, at 08:48, Stan Hoeppner wrote: >> >> Tell me about this "top-secure" aspect of Squirrelmail again. ;) > > The fact that some spammers are able to get into email accounts and send spam > via squirrelmail has nothing to do with the security of squirrelmail itself. > In nerely all, if not all, of these cases the account is being compromised > due to having a password like "password1" or "12345678" If you'd have read past the first line you'd have noticed I said the same thing. ;) -- Stan
Re: Scalable
Aaron Wolfe put forth on 2/12/2010 11:39 AM: > It might be better to think in terms of messages per hour than number of > users. Most importantly, who are these users? Are they customers? Members of some society or club? Will these be their primary email accounts or secondary, tertiary, etc? If these are nursing home residents you could get by with an old 386. ;) Who are your users? The answer to this question will probably answer most of the others. -- Stan
Re: Scalable
Jonathan Tripathy put forth on 2/12/2010 3:50 PM: > 2.8 Dual Core > 2GB RAM What about disk? Disk is typically the key subsystem for mail performance. Fast CPUs don't do much for mail without a fast disk subsystem. At minimum get hardware mirroring for two disks (RAID 1) and best to make them 10K or 15K rpm models. 7.2K rpm disks might not cut it for 600 users unless you go hardware RAID 10 with 4 disks. > how much would that handle? With the right disk subsystem, those specs above with Postfix + Dovecot IMAP + antispam stuff + etc should be plenty. > My customer is a business, with 600 staff, however I think they just use > a single broadband connection so that will be the limiting factor, as > this dedicated server has a 100Mbps link to the net.. What is the up/down link speed of the broadband connection? If's it's something like the low ball minimum 1.5M/512K the speed of the server won't mean much, just as you surmise. And if that is the case, this smtp/imap server should be placed on site at the business location, not in a colo. Where is their current mail server located? Also, you need to get some usage data from their current server to find out exactly what their flow volume is. -- Stan
Re: Scalable
Jonathan Tripathy put forth on 2/12/2010 5:05 PM: > Hi Stan, Hi. Try to keep the discussions on list so everyone can assist. > You've hit a very good question. They don't currently have an office > email system. Staff are using their personal Hotmail accounts when they > need to send the odd email. Do you see why I orignally was going to get > a 256MB RAM VM to allow them to have 50 or so email accounts? No, I can't. I can understand your thought process, but it's wrong. Leaving a really bad situation for another one that's not quite as bad is not the same as going to a good situation. Architect a solution that fits the client's needs, not a solution that's just a little better than what they have, but overall still doesn't come close to meeting their needs. > Just some other company has come in saying that they'll do 600, and even > though my price is much cheaper, it's now being seen as "too cheap"... Bid the job right. Write up a proposal explaining what they need, why they need it, and how much it's going to cost. > I was thinking this server: > > http://www.fasthosts.co.uk/dedicatedservers/linux-servers/ds300-linux/ You're still not looking at this from the proper perspective. You're looking at ISP rented colo offerings and trying to match one you think might fit the client's need. This is called an "ass backwards" approach to system design. Identify the client's needs, then architect the system, then pick the hardware, vendors and providers that best fit that need. You didn't mention what their broadband connection speed is. We need to know that to help you properly architect this thing. The lower that bandwidth, the greater the need to have the mail server on site and not in a colo. To be completely honest, from what I've seen from you to this point, it sounds like everyone in this scenario might be better off just using Google apps. Charge a decent "conversion" fee, add in some training, and once they're up and running you don't have to "manage the box", which it seems you're not really up to anyway. -- Stan
Re: how to specify a "default key" in access(5)
Wietse Venema put forth on 2/14/2010 12:52 PM: > regexp:/etc/postfix/recipients.pcre ^^ Wietse is this a typo or am I about to learn something new about regexp/pcre interchangeability/compatibility in Postfix? I'm assuming in the example above that the .pcre file actually contains pcre syntax, not regexp syntax. -- Stan
Re: Postfix - Timeout While Sending End of Data
DJ Lucas put forth on 2/15/2010 1:22 AM: > http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_24438893.html Never post links to information that requires a credit card in order to view it. I'm sure this breaks one if not many netiquette rules. ;) Surely there are many freely available texts with the relevant information that are just as good as this non-free text. -- Stan
Re: Postfix - Timeout While Sending End of Data
DJ Lucas put forth on 2/15/2010 1:33 AM: > On 02/15/2010 01:30 AM, Stan Hoeppner wrote: >> DJ Lucas put forth on 2/15/2010 1:22 AM: >> >> >>> http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_24438893.html >>> >> Never post links to information that requires a credit card in order to view >> it. >> I'm sure this breaks one if not many netiquette rules. ;) >> >> Surely there are many freely available texts with the relevant information >> that >> are just as good as this non-free text. >> >> > My apologies to the list. Didn't even think of that. In my (admittedly > weak) defense, you can scroll to the bottom of the page and get the > accepted solution and OPs responses without a CC for Experts Exchange. I can't get to it without entering a CC and starting a 30 day trial. The "bottom" of the page is white space. I see no options anywhere on the page to get at the info without signing up. This is kinda by design isn't it? No pay, no play? It's the whole point of the Experts Exchange website is it not? Due to your membership and cookies, even if you aren't logged in, you're probably still seeing a different page than those without a membership and prior cookies already on the the PC accessing the site. It's a no go. -- Stan
Re: deliver problem ( Error: file_dotlock_create )
Frank Bonnet put forth on 2/15/2010 3:10 AM: > On 02/12/10 18:25, Stan Hoeppner wrote: >> Frank Bonnet put forth on 2/12/2010 10:05 AM: >>> Hello all ( Postfix and Dovecot ) >>> >>> Trying to use deliver as mailbox_command with Postfix I get this >>> error each time an email is arriving >>> >>> deliver(): Error: file_dotlock_create(/var/mail/) >>> failed: Permission denied (euid=3003() egid=3010(smig) missing >>> +w perm: /var/mail) (set mail_privileged_group=mail) >>> >>> Doea this means I have to chmod 777 the /var/mail directory ? No. And never use 777. Avoid it at all costs. > Well I do use sieve to let Roundcube build email filters ... In that case I believe the answer is possibly in the error message itself: (set mail_privileged_group=mail) >From /etc/dovecot/dovecot/conf: # Group to enable temporarily for privileged operations. Currently this is # used only with INBOX when either its initial creation or dotlocking fails. # Typically this is set to "mail" to give access to /var/mail. mail_privileged_group = mail It appears your deliver process isn't running with the proper credentials to allow writing (+w in the err) to the user mail files. The error message, I believe, is telling you to set mail_privileged_group=mail in dovecot.conf Give that a shot and see if it fixes the problem. BTW, did this problem crop up on a production system, out of the blue? If so, did you make any changes, and what changes did you make? Or is this a new system and you're just setting it up? Or did you just switch from Postfix local delivery to dovecot LDA and the problems started? -- Stan
Re: Max Recipients in Postfix stripped to first 8?
jchase put forth on 2/18/2010 11:49 AM: > header_size_limit = 256 header_size_limit (default: 102400) The maximal amount of memory in bytes for storing a message header. If a header is larger, the excess is discarded. The limit is enforced by the cleanup(8) server. Your current header_size_limit is 256 characters. This is your problem. Count the line up to the first few letters of that 9th email address and you'll hit 256 at the last letter before the truncation. Remove this line from your main.cf to re-enable the default of 102,400 bytes and your problem is solved. Don't forget to "/etc/init.d/postfix reload" after the change. -- Stan
Re: Max Recipients in Postfix stripped to first 8?
Stan Hoeppner put forth on 2/18/2010 12:21 PM: > jchase put forth on 2/18/2010 11:49 AM: > >> header_size_limit = 256 > > header_size_limit (default: 102400) > > The maximal amount of memory in bytes for storing a message header. If a > header is larger, the excess is discarded. The limit is enforced by the > cleanup(8) server. > > > Your current header_size_limit is 256 characters. This is your problem. > Count > the line up to the first few letters of that 9th email address and you'll hit > 256 at the last letter before the truncation. I should have said start counting at the first character of the complete header, and you'll hit 256 characters where it cuts off at that 9th recipient address. Remember to count spaces and carriage returns. > Remove this line from your main.cf to re-enable the default of 102,400 bytes > and > your problem is solved. Don't forget to "/etc/init.d/postfix reload" after > the > change. -- Stan
Re: rbl sites
Ralf Hildebrandt put forth on 2/19/2010 12:35 PM: > * mouss : > >>> Your DNS lookups are broken: > ... >> or spamhaus blocks his DNS server. > > Yes, but that's within my interpretation of "Your DNS lookups are > broken" :))) Recall my recent thread about this. I had switched my resolvers to Google public DNS and it broke zen, silently in my case. Once the fine folks here helped me figure out the problem, and upon resulting recommendations, I installed pdns_recursor on my postfix MX and all is good with the dns/rbl world once again. ;) pdns_recursor is tiny and miserly on resources. Set its cache to like 8192 and forget you installed it. Works great. -- Stan
Re: How to manage local blacklist on my postfix relay?
Patrick Chemla put forth on 2/19/2010 1:38 AM: > Hi, > > I have a Postfix 2.6 relaying tons of emails to millions email addresses > and domains. > > I have listed tens of thousands of email addresses and domains to which > I don't want to relay any more. The plot thickens... First you said you were sending legit bulk advertising email only to French recipients, on behalf of a single client. Today you say you've been relaying email for tens of thousands of email addresses and domains to millions of destination email addresses. You're now telling us a different story about what you're doing, which makes you, at the very least, a liar. So let me play sucker and inquire, who owns these tens of thousands of email addresses and domains for which you are relaying email? -- Stan
Re: How do I get spam through my pre-queue spam filter?
dar...@chaosreigns.com put forth on 2/19/2010 11:26 PM: > I want to collect all spam delivered to my server to an invalid user / > domain. luser_relay seems to be doing part of the job, but how do I get it > around or through spamassassin which is set up as a pre-queue content > filter? It looks like skipping the smtpd_proxy_filter isn't an option, so > can I set a header or something for spamassassin to whitelist on? > > > I love running spamassassin as a pre-queue filter, knowing that any false > positives will get an error message, without causing any backscatter. > > (Honey pot, for maintenance of whitelist / blacklist type things.) Just add smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/honey_pot_whitelist at the very top of your smtpd_recipient_restrictions list. /etc/postfix/honey_pot_whitelist # white list honey pot addresses honey-...@yourdomain.comOK sw33t3r-...@yourdomain.com OK sw33t3st-...@yourdomain.com OK All of the above assumes you're using the "all smtpd_foo_restrictions are consolidated into smtpd_recipient_restrictions" style main.cf. If you're using the classic style, with separate smtpd_foo_restrictions sections, you'll need to add the check_recipient_access line to the very top of each of section, because an OK in one section means nothing when the next restriction section gets evaluated. "First match wins" but only within a given restriction section. smtpd_client_restrictions smtpd_sender_restrictions smtpd_helo_restrictions smtpd_recipients_restrictions -- Stan
Re: rbl sites
brian moore put forth on 2/22/2010 12:57 PM: > I like Spamhaus, and it is very effective, though they do charge a > nontrivial fee for commercial usage that would never get approved around here. You may be pleasantly surprised to find out you do qualify for free use. http://www.spamhaus.org/organization/dnsblusage.html *Definition: "non-commercial use" is use for any purpose other than as part or all of a product or service that is resold, or for use of which a fee is charged. For example, using our DNSBLs in a commercial spam filtering appliance that is then sold to others requires a data feed, regardless of use volume. The same is true of commercial spam filtering software and commercial spam filtering services. If you're non-commercial, and at less than 100,000 SMTP transactions per day, and less than 300,000 dnsbl queries per day, then you qualify for the free service. -- Stan
Re: How to tell which instance is which
Wietse Venema put forth on 2/23/2010 10:39 AM: > Not all the world > is Linux. In fact there are 10 times as many Macs. Wietse Venema put forth on 2/16/2010 10:01 AM: > This is a technical mailing list. When you claim that something is > bad, you need to support that claim with actual evidence. Otherwise, > you are just spreading rumors. Linux = operating system MAC = computer (usually runs MAC OSX but not always) Given worldwide Linux use on desktops, laptops, and servers, and given that the vast majority of Macintosh PCs and servers are sold into the US market only, I have trouble believing there are 10x more OSX installations worldwide than Linux. In fact, I would venture to guess it's the other way round, but with an even higher ratio. I have no hard figures to support this, but I'm guessing you don't either. Come to think of it, if one were to merely count the number of supercomputer cluster nodes running Linux the resulting sum would probably be more than all Macs sold throughout history. A single Cray XT4/5 Linux cluster at ORNL alone has 45,208 Linux compute nodes. This sum doesn't include the hundreds of login and filesystem nodes all running Linux. Add to this total every Linux cluster node at US government labs of various sorts, and the number of nodes running Linux is into the tens of millions. Now do the same for every nation's governement lab clusters. Now do the same for universities. We're probably now well over 20 million Linux nodes just for scientific compute clusters. Now lets add all the nodes run for Google search, a few hundred thousand worldwide, and Gmail, and Google apps. Now add in the millions of web servers of all kinds around the world running a LAMP stack or Lighttpd for image or video serving. How about all the VPS hosting offered by ISPs and colocation facilities? Most of those run Linux. Need we count Linux on the desktop in China and India? Russia? I'm pretty sure MAC OSX is fighting an uphill battle with Linux when it comes to the numbers game, and losing badly. If Apple were to release OSX as a standalone product, the trend might change a bit, though not enough for OSX to take the numbers lead. Linux offers to much choice and control, and it's free. These qualities are difficult for its competition to overcome especially amongst populations who are not yet victims of vendor lock in. ;) -- Stan
Re: How to tell which instance is which
Wietse Venema put forth on 2/23/2010 11:41 AM: > Stan Hoeppner: >> Wietse Venema put forth on 2/23/2010 10:39 AM: >> >>> Not all the world >>> is Linux. In fact there are 10 times as many Macs. >> >> Wietse Venema put forth on 2/16/2010 10:01 AM: >>> This is a technical mailing list. When you claim that something is >>> bad, you need to support that claim with actual evidence. Otherwise, >>> you are just spreading rumors. >> >> Linux = operating system >> MAC = computer (usually runs MAC OSX but not always) >> >> Given worldwide Linux use on desktops, laptops, and servers, and given that >> the vast majority of Macintosh PCs and servers are sold into the US market >> only, I have trouble believing there are 10x more OSX installations >> worldwide than Linux. In fact, I would venture to guess it's the other way >> round, but with an even higher ratio. I have no hard figures to support >> this, but I'm guessing you don't either. > > Here is one example: > http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=8 >From that same page: Market Share Help Operating System This report lists the market share of the top operating systems in use for browsing (not servers). This data is derived by aggregating the traffic across our network of websites that use our service. Not very applicable since most desktops don't run an MTA, and not very thorough since the data is strictly collected on clients connecting to Netmarketshare's web servers. It's unfortunate that there is no easy systematic way to collect server OS market share data. Even Netcraft only has httpd stats not OS stats. I concede Victor's point, obviously. I'm arguing Postfix' multi-platform support, which is fantastic. I'm merely playfully, academically, jousting with you over the Mac vs Linux numbers comment, which I believe to be upside down in favor of the wrong fighter (boxing analogy). If you'd have said "Postfix must work not only with Linux, but also *BSD, AIX, Solaris, and other Unix style OS's" I'd have never responded. -- Stan
Re: How to tell which instance is which
Sahil Tandon put forth on 2/23/2010 12:53 PM: > Stan can you take this pedantic nitpicking off-list if you must > persist? Thanks. No need to go off-list. This poor dead horse has been beaten enough, I think. Sorry to have been in pedant mode. /~$ /usr/bin/wishful_commands/pedant off -- Stan
Re: bogus HELO name used
Daniel Morgan put forth on 2/26/2010 12:04 AM: >> myhostname = apac3.apac.org.ni > > In DNS: apac3.apac.org.ni = 165.98.119.11 > BUT > 165.98.119.11 != apac3.apac.org.ni > 165.98.119.11 == pppleon11.ibw.com.ni. Post the rejected transaction(s) from your logs please. It's likely they are rejecting your mail due to the presence of "ppp" in the rDNS name, which typically indicates consumer broadband IP space. I block smtp connections based on such rDNS names myself, as do many admins. If you are sending mail from dynamic IP consumer space, I recommend reading this document: http://www.hardwarefreak.com/postfix-adsl-relay-config.txt -- Stan
Re: RBL problem?
David Schraeder put forth on 2/26/2010 2:13 PM: > How are you guys getting those stats on the blocks? Alternatively, try pflogsumm: http://jimsun.linxnet.com/postfix_contrib.html If you use Debian you can install pflogsumm via aptitude. -- Stan
Re: Spam Attack on Postmaster
Carlos Williams put forth on 2/28/2010 1:55 PM: > On Tue, Oct 27, 2009 at 8:55 AM, Noel Jones wrote: >> Or you can have postfix add it to main.cf for you by typing the command: >> >> # postconf -e 'address_verify_sender=$double_bounce_sender' > > I added the above parameter > (address_verify_sender=$double_bounce_sender) in my main.cf to keep > spammers from sending spam / junk email to my built in Postmaster > account. I am running a dated version of Postfix 2.3. I added it in my > main.cf and reloaded Postfix. I see it listed in my 'postconf -n' & > just this weekend received this email: Carlos, I think it's time you join spam-l and learn all the tricks to fighting spam. http://spam-l.com/mailman/listinfo/spam-l The host that sent you this "postmaster" spam is infected with a spam bot. The IP address is listed on no less than 7 dnsbls. The IP address is dynamic, with generic rDNS. inetnum:89.204.36.0 - 89.204.49.255 netname:USI_ADSL_USERS5 descr: Dynamic distribution IP's for broadband services 160.40.204.89.access.ttknet.ru You could have blocked this spam with any number of methods, the simplest being adding the following to main.cf: smtpd_recipient_restrictions = reject_rbl_client zen.spamhaus.org If you don't need to receive email from Russia, ever, period, you can use the data at ipdeny.com to build a cidr table and block _ALL_ mail from Russia. You can do this for any country. -- Stan
Re: Spam Attack on Postmaster
Carlos Williams put forth on 2/28/2010 10:02 PM: > On Sun, Feb 28, 2010 at 5:27 PM, Stan Hoeppner wrote: >> Carlos, I think it's time you join spam-l and learn all the tricks to >> fighting spam. http://spam-l.com/mailman/listinfo/spam-l > > Thanks. I will research this and see what I can learn from that list. If you sub the list, ask Rich K about ipdeny. I learned about it from him. He's been a spam fighter since 1994 (maybe earlier). He's old school. As is Chris Lewis. Pay close attention to his posts. He's head of network security at Nortel networks, as well as the creator/maintainer of a major dnsbl, although I can't say which, lest I be shot. ;) The creator of Enemies List, Steven Champeon, is also a member, very sharp guy. Lots of experience on spam-l going waaay back. Many of the folks on the list predate SMTP. >> You could have blocked this spam with any number of methods, the simplest >> being adding the following to main.cf: >> >> smtpd_recipient_restrictions = >> reject_rbl_client zen.spamhaus.org > > I do have this in my main.cf. I don't know why it didn't reject it if > I have zen.spamhaus.org in my config unless it was added after the > spam was sent to me. Do you know? I have attached my output of > 'postconf -n' below. Look at the date/time stamp on the email transaction in your log, then check it against the CBL. If you reported it here the same day you received it, then CBL already had it listed. The CBL is incorporated into Spamhaus ZEN, but it's easier to check if an IP is listed using the CBL website than the Spamhaus website. > Is the a guide on how I can build a cidr table and block ALL mail from > Russia? I don't ever want / need mail from Russia and don't know how > to build this table and how to force Postfix to use the list. You don't need a guide. Just download the country files you want to block from ipdeny.com and add "REJECT" to the end of each line in the file so Postfix can use it, something like this: sed 's/$/ REJECT Russian email not welcome/g' ru.zone > russia.cidr Stick russia.cidr in /etc/postfix/ and to smtpd_recipient_restrictions, close to the top, add: check_client_access cidr:/etc/postfix/russia.cidr This will block all smtp connections originating from Russian IP space. Using ipdeny country listings is a simple and very effective way to stop a lot of spam. If you are sure you'll never need to receive email from a given country, using ipdeny cidr listings is the single most effective way to block spam from those countries. It's cheap on resources too, compared to dnsbl lookups. -- Stan
Re: tls vs ssl
Daniel L. Miller put forth on 3/2/2010 1:18 AM: > OK - I'm an idiot. I'll just admit that up front and get it out of the > way. > > Now that that's settled, what is the difference between "SSL" and "TLS" > in a MUA - particularly Thunderbird - in a Postfix context? > > I would have sworn I used to use Thunderbird with "SSL" specified and > connected to my Postfix servers fine. Now, I can only connect in "TLS" > mode. What did I break? It's unlikely you'd forget setting up SSL. You would have likely created a self signed server certificate and would have installed it on all clients connecting to the server, just as must be done with web browsers connecting to a secure site for the first time. You've likely been using STARTTLS only, which doesn't require a key exchange as SSL/TLS does. STARTTLS != TLS. -- Stan
Re: tls vs ssl
Bill Landry put forth on 3/2/2010 2:01 AM: > On 3/1/2010 11:51 PM, Stan Hoeppner wrote: >> Daniel L. Miller put forth on 3/2/2010 1:18 AM: >>> OK - I'm an idiot. I'll just admit that up front and get it out of the >>> way. >>> >>> Now that that's settled, what is the difference between "SSL" and "TLS" >>> in a MUA - particularly Thunderbird - in a Postfix context? >>> >>> I would have sworn I used to use Thunderbird with "SSL" specified and >>> connected to my Postfix servers fine. Now, I can only connect in "TLS" >>> mode. What did I break? >> >> It's unlikely you'd forget setting up SSL. You would have likely >> created a >> self signed server certificate and would have installed it on all clients >> connecting to the server, just as must be done with web browsers >> connecting >> to a secure site for the first time. >> >> You've likely been using STARTTLS only, which doesn't require a key >> exchange >> as SSL/TLS does. STARTTLS != TLS. > > Huh, what? STARTTLS == Start TLS > > http://en.wikipedia.org/wiki/STARTTLS He's talking about Thunderbird Bill. In that context, IIRC, one can check the STARTTLS option box, and if the outgoing SMTP server doesn't support STARTTLS, Thunderbird fails gracefully without error and falls back to plain text mode. If, on the other hand, one checks SSL/TLS, you don't get the graceful failure, but a hard error. This is the context of my STARTTLS != TLS comment. It's been a very long time since I messed with this, probably pre 2.0, so my memory could be a little foggy. I would hope the Mozilla team would have changed this behavior in recent revs of T-Bird. -- Stan
Re: Error main.cf path, is it just me or is it a bug ?
Gregory BELLIER put forth on 3/2/2010 6:03 AM: > Hi ! > > I downloaded postfix-2.7.0 and I need to manually build it. > The goal is to place everything in a different folder than usual : > /opt/postfix http://www.postfix.org/INSTALL.html 4.4 - Overriding built-in parameter default settings All Postfix configuration parameters can be changed by editing a Postfix configuration file, except for one: the parameter that specifies the location of Postfix configuration files. In order to build Postfix with a configuration directory other than /etc/postfix, use: % make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/where\"' % make IMPORTANT: Be sure to get the quotes right. These details matter a lot. (Found the answer in less than 60 seconds with Google--1st hit, first sub entry, searching for "/etc/postfix hard coded") -- Stan
Re: Out: 452 Insufficient system storage
donovan jeffrey j put forth on 3/1/2010 8:06 AM: > Greetings > > I had several of these on my primary MX this weekend and one just popped > up. Can someone explain where this Insufficient system storage is ? What filesystem are you using? Are you running out of inodes? /$ df -i -- Stan
Re: Saving to Sent folder
Ansgar Wiechers put forth on 3/3/2010 6:37 AM: > On 2010-03-03 Jonathan Tripathy wrote: >> I'm not sure if there is a solution to this, but maybe one of you >> folks will know a "workaround". >> >> After thunderbird has sent the email, it then has to save the email to >> the sent items folders. This can take a long time if there is an >> attachment and the server is remote. > > This is done via IMAP, so it's a Dovecot rather than a Postfix issue. > > A workaround might be to configure Thunderbird to not store a copy of > your sent mail and instead have Postfix BCC a copy to yourself. Or you > could simply not send large attachments via e-mail. There is zero advantage to your BCC suggestion. The BCC copy is still going to have to end up on his remote IMAP server. Just store the sent items in Local Folders/Sent Items. I do this and it works great. My Dovecot server is local, 100BaseT, and it's still noticeably faster to store Sent Items locally on the workstation. -- Stan
