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
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
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 pkg-roundcube-maintain...@lists.alioth.debian.org 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 installneglect 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 carlosw...@gmail.comwrote: On Tue, Feb 2, 2010 at 8:36 AM, Charles Marcus cmar...@media-brokers.com 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 s...@hardwarefreak.com; 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: 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: 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 njo...@megan.vbhcs.org 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: snip 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 s...@hardwarefreak.com 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 snip 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
spamhaus dbl implementation
What's the best way to integrate the Spamhaus DBL for folks not already using SA et al? Will the following work, or does it check only the entire hostname, and not the domain portion in isolation as well? smtpd_recipient_restrictions = reject_rhsbl_client dbl.spamhaus.org -- Stan
Re: Saving to Sent folder
Ansgar Wiechers put forth on 3/3/2010 9:01 AM: I was under the impression that his Postfix and Dovecot are running on the same (remote) host, and he's using Postfix as a smarthost for his outbound mail. If that's the case, then there certainly is an advantage, as his client won't have to transfer the message twice. Otherwise you're correct, of course. The point I was making is that the BCC'd copy is dropped in his inbox. Thus, when he opens his MUA, he still has to download the BCC'd sent items and move them to his IMAP sent items folder. So there's no net gain in IMAP traffic reduction. I suppose it might be possible to hack together a solution in the MTA or IMAP server, manually dropping copies of sent messages in the user's IMAP Sent Items folder. That would be one heck of a kludge though. Just store the sent items in Local Folders/Sent Items. I do this and it works great. You're giving up the advanteges of IMAP, though. Life is full of imperfect choices. You can't have your cake and eat it too, etc, etc. My Dovecot server is local, 100BaseT, and it's still noticeably faster to store Sent Items locally on the workstation. Well, duh. Even old PATA/33 drives have almost three times the transfer rate of 100BaseT. Transfer rate isn't the issue, but latency. Local disk writes are buffered, whereas network writes via IMAP are not. Thus, writing locally involves latency in nanoseconds because your MUA is writing to in-memory disk buffers. Over IMAP it's milliseconds due to TCP/IP stack and wire latency. The speed of the local disk is pretty much irrelevant these days for this scenario. -- Stan
Re: spamhaus dbl implementation
Noel Jones put forth on 3/3/2010 7:16 PM: additionally, it appears that dbl.spamhaus.org lists wildcard subdomains. So for example if dbl lists spammer.tld and the HELO name is random.foo.spammer.tld it should still be caught by reject_rhsbl_helo. Checking the HELO name against the DBL is an ok start, but I'd really like to be able to check rDNS domain name and/or A record domain name against the DBL as well. Is there no Postfix check available for this? This is good; looking forward to seeing results. Me too. As with any new (or newly added to your config) RBL, it's prudent to try it out for a while with warn_if_reject to prevent accidents. Yep. -- Stan
Re: spamhaus dbl implementation
Noel Jones put forth on 3/3/2010 7:16 PM: smtpd_recipient_restrictions = reject_rhsbl_client dbl.spamhaus.org (note for the archives: that's not a complete smtpd_recipient_restrictions statement.) BTW, what is incomplete WRT the above restriction example I gave? reject_rhsbl_client rbl_domain=d.d.d.d Reject the request when the client hostname is listed with the A record d.d.d.d under rbl_domain (Postfix version 2.1 and later only). If no =d.d.d.d is specified, reject the request when the client hostname is listed with any A record under rbl_domain. See the reject_rbl_client description above for additional RBL related configuration parameters. This feature is available in Postfix 2.0 and later. -- Stan
Re: spamhaus dbl implementation
/dev/rob0 put forth on 3/3/2010 10:31 PM: On Wed, Mar 03, 2010 at 09:29:50PM -0600, Stan Hoeppner wrote: Noel Jones put forth on 3/3/2010 7:16 PM: smtpd_recipient_restrictions = reject_rhsbl_client dbl.spamhaus.org (note for the archives: that's not a complete smtpd_recipient_restrictions statement.) BTW, what is incomplete WRT the above restriction example I gave? I think you know; smtpd_recipient_restrictions must include a restriction which will prevent open relaying. A complete way to show a partial smtpd_recipient_restrictions example is with ellipses: smtpd_recipient_restrictions = [ ... ] reject_rhsbl_client dbl.spamhaus.org[, ... ] Thus implying to the reader that more is needed here, and s/he would be well advised to look it up in postconf(5) documentation. It's no big deal, but someone who Googles your post could end up frustrated. Got it now. I thought I was being called out for incorrect syntax whilst using a client restriction in the recipient restriction section. Spent 15 minutes in docs trying to figure out what I had wrong...nothing. I'll try to be mindful and add section filler in the future to avoid this possible problem for Googlers. -- Stan
Re: spamhaus dbl implementation
Ralf Hildebrandt put forth on 3/4/2010 1:55 AM: The Spamhaus DBL is a realtime database of domains (typically web site domains) found in spam messages. Mail server software capable of scanning email message body contents for URIs can use the DBL to identify, classify or reject spam containing DBL-listed domains. Two paragraphs later, on the same Spamhaus web page: The DBL is both a domain URI Blocklist and RHSBL. It is intended primarily for message body URI checks but it can additionally be used for connection checks at the SMTP level and header domain checks (HELO, connecting IP rDNS domain, From Reply-To domains, Message-ID domain) and other checks involving domains. So, can I use the following to reject connections whose A record is in the Spamhaus DBL? Does this also query for the domain in the PTR/FQrDNS record? smtpd_client_restrictions = ... reject_rhsbl_client dbl.spamhaus.org ... Thanks. -- Stan
Re: Saving to Sent folder
J. Roeleveld put forth on 3/4/2010 2:12 AM:
On Thursday 04 March 2010 08:57:30 Jonathan Tripathy wrote:
Hi Everyone,
Thanks for all the tips.
Postfix and Dovecot are indeed on the same box and I do agree with you that
it would require one heck of a hack to get this to work.
See below, it might be a simple configuration still?
Since this is software, it is possible, just maybe not with the current
implementation of the 2 bits of software. It would be nice if postfix had
some sort of setting to allow an external program to take a copy of the
email being sent. Then, dovecot (again probably a hacked version) could
store the email in the sent items folder.
As for the BCC idea, this could work, but only if postfix was able to
prefix the subject with something like [sent], or even better add a
header, then dovecot can filter to the correct folder. Is this possible?
Can't you filter this on the from field?
Eg:
If from = my email then
{
store in sent items
} else {
store in inbox / parse other rules...
}
With that, I thought there is an option in postfix to bcc a single address on
all emails?
You could then put a filter like the following on all emails coming into that
address:
if from in list of local emails then
{
store in correct Sent Items
} else {
discard email as we don't want to duplicate incoming email
}
Would sender_bcc_maps work if he uses Dovecot LDA/sieve? He could create a
sieve filter based on MAIL FROM: being his own address, and have sieve move
all such mails into his Sent Items folder. Might be worth a shot?
--
Stan
Re: outbound sender
Len Conrad put forth on 3/4/2010 4:16 AM: If listsen...@domain.tld, send to Internet Else, send to MX gateway This may be what you're looking for. http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps 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: outbound sender
Len Conrad put forth on 3/4/2010 6:40 AM: But we don't have a relayhost for the sender listsen...@domain.tld. We want that trusted sender to bypass the (scanning, weak) relayhost and nexthop to Internet. in the sender_dependent postfix box, relayhost = [mx.domain.tld] sender_dependent_relayhost_maps = sender_dependent_relayhost.map ... which would contain what, the null next hop? listsen...@domain.tld smtp: It would be of the form listsen...@domain.tld smtp:10.1.2.3 10.1.2.3 being the new/big Postfix box you mentioned wanting to send this list mail through. But upon further reading, I'm not sure if you need that, or sender_dependent_default_transport_maps I'm pretty sure one of these two is what you need. One of the experts will jump in shortly with the definitive answer (I hope/assume). -- Stan
Re: PATCH reject_rhsbl_reverse_client
Noel Jones put forth on 3/4/2010 2:51 PM: This patch adds a reject_rhsbl_reverse_client function that uses the unverified client hostname for the RBL lookup. Cool. Thanks Noel. The idea is that this might increase rhsbl hit rates if the hostname is more frequently available. On the other hand, spam-only domains seem to usually have verifiable hostnames, so I'm not sure how much this will really help. I don't quite follow your second statement here. Isn't this patch supposed to grab the domain name from the client's rDNS name? Snowshoe spammers usually do have reverse name records for all their sending IPs, so this should work great (assuming the RHS dnsbls are listing the domains). For instance, here are 5 snowshoe ranges at a spam facilitator ISP I recently did research on. 33K+ snowshoe IPs all with rDNS names: http://www.hardwarefreak.com/eonix.rdns.txt http://www.hardwarefreak.com/eonix2.rdns.txt http://www.hardwarefreak.com/eonix3.rdns.txt http://www.hardwarefreak.com/eonix4.rdns.txt http://www.hardwarefreak.com/eonix5.rdns.txt If the Spamhaus DBL was listing all the domains in the 5 pages above, would this patch not reject connections from all these hosts? This is the goal of this patch, right? -- Stan
Re: reverse dns fails with multiple domains
John WInther put forth on 3/6/2010 12:57 PM: Thanks for info, I am aware of the manual and I have previus tryed to change the myhostname to soapnut.dk, I still got the reverse dns error. I gave me an idear to reverse resolve the ip address registred in mx, and the reply from that test was the dns name of my internet access. 0xbcb75b12.cpe.ge-1-1-0-1112.customer.tele.dk, when i put that in as myhostname the reverse dns lookup reply with success. RFC does not dictate that your forward and reverse dns names match. It does dictate that a domain name must be valid. Anything ending in .local is not valid. I'd suggest against using 0xbcb75b12.cpe.ge-1-1-0-1112.customer.tele.dk as your Postfix HELO name. Use a hostname based on one of your mail domains instead. Some sites will block SMTP servers that HELO with such a generic hostname as that above. -- Stan
Re: reverse dns fails with multiple domains
Greg A. Woods put forth on 3/6/2010 2:58 PM: At Sat, 06 Mar 2010 14:42:13 -0600, Stan Hoeppner s...@hardwarefreak.com wrote: Subject: Re: reverse dns fails with multiple domains RFC does not dictate that your forward and reverse dns names match. Common sense and common decency do though -- since if the forward and reverse names are not all orthogonal then the DNS lies, either by omission, or outright. Apparently you've missed past discussions here showing some examples of why this can be neither practical or desirable in some situations. For every hostname pointing at an IP address, there should be a corresponding PTR for that address pointing back at the hostname. When you say hostname, are you talking A record? Are you talking all IPs in general, or only MX hosts, or SMTP sending hosts? Does a web server ever need a PTR? Do any web browsers ever look up a host via PTR? No. So why should a web server have a PTR? There's no real excuse for mis-matched forward and reverse DNS. If you're going to show your reverse DNS to the world, then do it right. A web server with a single IP address hosting 378 vitural domains. Should it have 379 PTRs? One for the host itself and one for each virtual domain? Of course not. A mail server with a single IP address hosting 378 mail domains? Should it have 379 PTRs? One for the host itself and one for each virtual MX domain? Of course not. In this case, the DNS infrastructure isn't smart enough to return matching records even though they do exist, so why bother? You're living in a perfect world where everything has a 1:1 relationship in DNS. In the real world, this isn't the case, and probably never will be. I argued your position for years until I was blue in the face. You know what it gained me? A blue face. Nothing else. BTW, please keep list correspondence on list. I don't see any reason why your reply needed to be off list. -- Stan
Re: reverse dns fails with multiple domains
mouss put forth on 3/6/2010 3:01 PM: so OP not only has a generic name, but it doesn't resolve back to the IP. If he can get his ISP to fix his reverse (preferably using a custom reverse), then maybe things will get better. I assume this is difficult if not impossible, given it appears residential, so I recommended fixing what he could, the HELO name. And yes, many sites will block that PTR string at client name lookup as well as HELO lookup, but I think the probability is higher with HELO. -- Stan
Re: reverse dns fails with multiple domains
John WInther put forth on 3/6/2010 4:18 PM: My primary concern is that some mailservers deny sending mail to my domains if the reverse dns lookup fails. If I set myhostname to one of my public domains, the reply string from HELO is ok, but the reverse dns lookup fails, If not possible to satisfy both issues what is best configuration?. I still don't understand what reverse dns failure you're talking about. Please paste the failure info page or link from mx toolbox so we understand exactly what you're talking about. -- Stan
Re: reverse dns fails with multiple domains
mouss put forth on 3/6/2010 6:03 PM: Stan Hoeppner a écrit : [snip] A web server with a single IP address hosting 378 vitural domains. Should it have 379 PTRs? One for the host itself and one for each virtual domain? Of course not. A mail server with a single IP address hosting 378 mail domains? Should it have 379 PTRs? One for the host itself and one for each virtual MX domain? Of course not. In this case, the DNS infrastructure isn't smart enough to return matching records even though they do exist, so why bother? Stan, you're confused. What is asked for is: I'm not confused at all mouss. I was mocking Greg with an absurd example of what he espouses here: Greg A. Woods put forth on 3/6/2010 2:58 PM: For every hostname pointing at an IP address, there should be a corresponding PTR for that address pointing back at the hostname. My example exactly matches what he says. What he says is incorrect. I was drawing attention to his absurd suggestion with an example of absurdity. -- Stan
Re: Integration with Active Directory
Zhang Huangbin put forth on 3/12/2010 6:36 AM: On Mar 12, 2010, at 2:59 PM, Goutam Baul wrote: Hello Everybody, I am facing a scenario where the client needs a mailing solution while the user information will be kept in a Microsoft Active Directory server. I was trying to search for any material that talks about whether it is possible to make postfix and courier-imap talk to Microsoft ADS. I have done implementation with Open LDAP but not with ADS. Another work around might be to have LDAP for the mailing solution and create an application for user management that ensures that the LDAP and the MDS are always in sync. This would not be an elegant one and it would be great if the mailing solution (postfix,courier-imap,courier-authlib all in Linux] could talk to the ADS. May I request for some pointer please? You can try Postfix + Dovecot + Windows Active Directory 2003 + Roundcube webmail. I deployed one for customer based on iRedMail, works like a charm. Postfix and Dovecot can auth user against AD directly, include normal user, mail list, and Roundcube can use AD as global LDAP address book too. :) I concur. Ditch courier and go with Dovecot. If you're using Postfix, you may as well use the IMAP server that integrates best with it: http://www.dovecot.org Nice AD setup directions for Postfix and Dovecot: http://www.linuxmail.info/postfix-dovecot-ldap-centos-5/ -- Stan
Re: how quotas works with postfix and dovecot
Wilberth Pérez put forth on 3/12/2010 9:57 AM: Hi everybody any one knows, how i could edit dovecot to assign user quotas ? You are asking on the wrong list. Please use: http://www.dovecot.org/cgi-bin/mailman/listinfo/dovecot mailto:dove...@dovecot.org -- Stan
Re: Redefining myhosname to a location outside of main.cf
Wietse Venema put forth on 3/15/2010 10:22 AM: Since this does not work, is there an available option to move myhostname out of main.cf and into another file name or type? To set a fixed Postfix name, set the right hostname in main.cf, or set the right hostname in the kernel. If you need to change the Postfix name constantly, then that is an indication of illegitimate activities. I thought fast flux was out of vogue these days. Maybe Van Reuther is attempting to resurrect a variation on the theme. -- Stan
Re: RBL whitelist?
Erik Logtenberg put forth on 3/15/2010 11:16 AM: Hi, Is there a possibility to use a DNS-based RBL whitelist in Postfix? In The Netherlands we have an NL-Whitelist, which contains the IP's of all major ISP's. By using this whitelist one can make sure that accidental automatic blacklisting won't disrupt regular email traffic. I had something like a permit_rbl_client directive in mind, that could be placed in smtpd_recipient_restrictions, right before the reject_rbl_client lines. Apparently there is no permit_rbl_client at this moment, is there any other way to achieve this? DNS white lists are usually very, very small, relatively, compared to DNS black lists. This is why most DNS based white list providers enable zone transfers, in turn enabling customers to download the entire white list, which is then queried locally. Once it's local the tempfail issue is non existent. This is why nearly all DNS white list implementations are handled this way. It increases reliability fundamentally. DNS whitelists need to be fundamentally more reliable than DNS blacklists. How many records are in the DNSWL you mention? 200? 2000? There are a few million records in the Spamhaus and SORBS lists. If they tempfail, mail still comes through, although other A/S measures get a whack at it. If a DNSWL tempfails, you have more than a desired level of complexity to deal with this situation properly. Thus, it is optimal to deal with a local copy of the whitelist. What is preventing you from grabbing a copy of this .nl whitelist and querying against it locally either as a map file or via an RBLDNSD setup? -- Stan
Re: All email forward a copy to testing server
postfix users put forth on 3/19/2010 8:34 PM: Hi, I am migrating the Exchange 2000 to Exchange 2010, but before we switch over to new server, I want make a copy of email to new server for testing. Existing Config: Postfix - Amavisd - Exchange 2000 Here what I want : Postfix --- Amavisd - Exchange 2000 --- Exchange 2010 Is it possible? Or it is better forward all email before Postfix? email -- some program? -- Postfix --- Amavisd - Exchange 2000 -- Exchange 2010 What does Microsoft recommend? Your migration has nothing to do with Postfix but everything to do with Exchange. -- Stan
Re: ot: opinions about NiX Spam
Voytek Eymont put forth on 3/20/2010 5:52 PM: one of the blacklist I use it is ix.dnsbl.manitu.net to my knowledge, it has been OK since I've set it up, with no known complaints what is the user's opinions on it's usefulness ? This is one of the downsides to fully automated low threshold trap driven dnsbls. Similar to SORBS, ix.dnsbl.manitu.net will list any IP that sends over the threshold amount of spam to its traps. I stopped using this dnsbl long ago for the same reason I stopped using SORBS--too many FPs and not nearly enough blocking of actual spam to justify continued use. That said, I only use dnsbls for outright blocking at smtp because I'm philosophically opposed to content filters such as Spam Assassin. That said, IMHO, the proper way to use ix.dnsbl.manitu.net, SORBS, and similar dnsbls is via scoring within something like Spam Assassin, but not for outright blocking. For quite some time now my other spam countermeasures are so effective that I'm rarely even querying my configured dnsbls, which are only Spamhaus ZEN and DBL. I just added DBL recently to test it and it catches a few per day, same as ZEN. YMMV. -- Stan
Re: Relaying and backskatter problem
Randy put forth on 3/24/2010 3:55 PM: dig -x 208.43.143.111 ;; ANSWER SECTION: 111.143.43.208.in-addr.arpa. 3600 INPTR 208.43.143.111-static.reverse.softlayer.com. Your problem isn't the Exchange server per se. Your problem is that you're forwarding spam to it, and its anti-spam software is better than that on your Postfix server, which causes the backscatter. Almost any mail coming to you from Softlayer IP space is going to be spam, most likely snowshoe. Softlayer is a generic ISP/COLO outfit with tons of resellers and terrible (non existent) customer vetting. They have few, if any, legit email sending customers. As you can see I've extensively SMTP blocked Softlayer over the years. I suggest you do the same. # Softlayer, Dallas 10/10/2008 66.228.112.0/20 REJECT 67.228.0.0/16 REJECT 74.86.0.0/16REJECT 208.43.0.0/16 REJECT 174.36.0.0/15 REJECT 75.126.0.0/16 REJECT 173.192.0.0/15 REJECT Beef up the anti spam capabilities on your Postfix server and this problem will go away. Either that or tell the Exchange admin to silently drop/discard/eat the spam instead of rejecting it back upstream. The former is the preferable route, the latter the lazy route. -- Stan
Re: reverse proxy
Glenn English put forth on 4/1/2010 5:42 PM: I was asking about Postfix running as a daemon on the firewall computer that handles routing and inspecting traffic between the WAN, the DMZ, and the LAN. This Postfix would intercept and inspect incoming SMTP connections (and drop some) before passing valid ones on to the real Postfix MTA running on a computer in the DMZ. A 3-hole PIX running Postfix, in other words. If you want all the edge security managed by one device, I'd suggest you look here: http://www.astaro.com/ and prepare to open the corporate pocketbook relatively wide depending on the size of your user base and WAN bandwidth. If you actually know enough about what you're doing, just punch a TCP 25 pub/priv PAT hole through your current F/W to your Postfix server and beef up your AS/AV countermeasures. We've talked about a plethora of such methods both here and on spam-l that you've seen. Using an SMTP proxy/relay on the F/W box and sticking your Postfix server in the DNZ is a useless, fruitless, labor hogging effort, complicating your network architecture and introducing new troubleshooting headaches, for _zero_ security gain. Proxies and DMZs look neat on paper and in theory, but in the real world, for 95%+ or more of deployed applications, including SMTP mail, they create far more problems than they could ever hope to solve. Any seasoned sysop shuns unneeded complexity. The KISS principle applies to IT as it does to most things. -- Stan
Re: Whitelist a host using check_client_access before the rbl check?
Hello Nicolas, Try this: Remove 'check_client_access hash:/etc/postfix/client_access' from smtpd_recipient_restrictions. Add the following line in main.cf somewhere before/above smtpd_recipient_restrictions: smtpd_client_restrictions = hash:/etc/postfix/client_access And make sure you 'postmap /etc/postfix/client_access' any time you make changes to the file. And obviously, 'postfix reload' whenever you make changes to main.cf. Hope this helps. Stan Nicolas KOWALSKI wrote: Hello, I would like to whitelist a specific host, because it is currently listed in the zen rbl, but I am unable to do so. Here is a sample log of the rejected host connecting to my postfix: Aug 4 14:17:17 petole postfix/smtpd[23545]: connect from 225.96.68-86.rev.gaoland.net[86.68.96.225] Aug 4 14:17:17 petole postfix/smtpd[23545]: setting up TLS connection from 225.96.68-86.rev.gaoland.net[86.68.96.225] Aug 4 14:17:17 petole postfix/smtpd[23545]: TLS connection established from 225.96.68-86.rev.gaoland.net[86.68.96.225]: TLSv1 with cipher ADH-AES256-SHA (256/256 bits) Aug 4 14:17:18 petole postfix/smtpd[23545]: NOQUEUE: reject: RCPT from 225.96.68-86.rev.gaoland.net[86.68.96.225]: 554 5.7.1 Service unavailable; Client host [86.68.96.225] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=86.68.96.225; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=ESMTP helo=demisel.dyndns.org Aug 4 14:17:18 petole postfix/smtpd[23545]: disconnect from 225.96.68-86.rev.gaoland.net[86.68.96.225] - I added the following line (full postconf -n below) to the smtpd_recipient_restrictions, before the rbl check: check_client_access hash:/etc/postfix/client_access - /etc/postfix/client_access contains: demisel.dyndns.org OK - the full configuration: petole:~# postconf -n alias_maps = hash:/etc/aliases append_dot_mydomain = no config_directory = /etc/postfix disable_mime_output_conversion = yes header_checks = regexp:/etc/postfix/header_checks inet_protocols = all local_recipient_maps = hash:/etc/postfix/local_recipients, $alias_maps mailbox_size_limit = 0 mailbox_transport = cyrus maximal_queue_lifetime = 60d message_size_limit = 0 mydestination = localhost, localhost.localdomain, petole, petole.lan, petole.dyndns.org, petole.demisel.net mydomain = $myhostname myhostname = petole.dyndns.org relay_domains = demisel.dyndns.org relay_recipient_maps = hash:/etc/postfix/relay_recipients relayhost = [mail.club-internet.fr] smtp_tls_CAfile = /etc/postfix/ssl/cacert.pem smtp_tls_loglevel = 1 smtp_tls_security_level = may smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_client_access hash:/etc/postfix/client_access, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_invalid_hostname,reject_unknown_hostname, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org, permit smtpd_tls_cert_file = /etc/postfix/ssl/petole-crt.pem smtpd_tls_key_file = /etc/postfix/ssl/petole-key.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_timeout = 3600s Any help would be appreciated, Thanks,
Re: spam status with postfix ( thank you )
Richard Foley wrote: This mail is just FYI and by way of saying: postfix and friends do a great job - many thanks! Hi Richard, I second your sentiments and would like to shout out a big thank you to Wietse for creating Postfix! I was at about the same point you are now for more than 2 of the last 3 years, with about 5 spam a day making it into my inbox. Over the last 6 months or so that number has steadily increased, and in the last month the curve has become much steeper, averaging 25-40 spam per day until just this past week. Over the weekend I implemented an access table and have started adding the class C network of each host successfully getting spam into my inbox. I'm down to less than 5 a day again. :) Give it a shot. It doesn't take much time at all and the results are well worth the effort. Stan
smart hosting issues
Hello fellow smart hosters, I've been running this way for 3 years now because I could never figure out how to wildcard everything else. Here's the top of my transport file (a very small portion of it): hardwarefreak.com smtp:[192.168.100.2] earthlink.net smtp:[smtp.sbc.mail.yahoo4.akadns.net] .earthlink.net smtp:[smtp.sbc.mail.yahoo4.akadns.net] sbcglobal.net smtp:[smtp.sbc.mail.yahoo4.akadns.net] .sbcglobal.net smtp:[smtp.sbc.mail.yahoo4.akadns.net] swbell.net smtp:[smtp.sbc.mail.yahoo4.akadns.net] .swbell.net smtp:[smtp.sbc.mail.yahoo4.akadns.net] sbc.com smtp:[smtp.sbc.mail.yahoo4.akadns.net] .sbc.comsmtp:[smtp.sbc.mail.yahoo4.akadns.net] yahoo.com smtp:[smtp.sbc.mail.yahoo4.akadns.net] .yahoo.com smtp:[smtp.sbc.mail.yahoo4.akadns.net] aol.com smtp:[smtp.sbc.mail.yahoo4.akadns.net] .aol.comsmtp:[smtp.sbc.mail.yahoo4.akadns.net] Is there a way to wildcard everything other than hardwarefreak.com? I'd sure like to have a two line transport file instead of 200. Any help in getting this fixed would be greatly appreciated. Thanks. Stan Hoeppner TheHardwareFreak
Re: smart hosting issues
Henrik K wrote: Sorry if I don't offer sympathies, but Postfix is notoriously well documented and maintained. A quick look into the man page will show you how it's spelled. You missed my point entirely, it seems... I agree that Postfix should warn in that case. I don't understand why it doesn't, and it baffles me that the two spellings have different functionality. And, given this state of affairs, what was that you were saying about the documentation? Care to point me to the docs that detail all of this? ;)
Re: regular access file vs CIDR
Henrik K wrote: On Thu, Aug 07, 2008 at 01:36:08PM -0500, Stan Hoeppner wrote: What changes would I need to make in order to start using CIDR notation in my access file? I'm currently using the standard hashed access file. http://www.postfix.org/documentation.html Lookup table overview -- http://www.postfix.org/DATABASE_README.html All Postfix lookup tables are specified as type:table, where type is one of the database types described under Postfix lookup table types at the end of this document ... cidr A table that associates values with Classless Inter-Domain Routing (CIDR) patterns. The table format is described in cidr_table(5). http://www.postfix.org/cidr_table.5.html That really didn't answer my question. I guess I need to be more specific: Is the CIDR file a plain text flat file? Do I need to run any commands against it to do the binary conversions or is that something Postfix does automatically on the fly? I'm a bit confused because I'm coming from using a hashed db file. The documentation doesn't state what the actual file type of a CIDR file is, it just says it's not in dbm or db format: The Postfix mail system uses optional lookup tables. These tables are usually in dbm or db format. Alterna- tively, lookup tables can be specified in CIDR (Classless Inter-Domain Routing) form. I.e., can I just edit my access file, converting the dotted doubles, triples, and quads to CIDR slash notation, and use it as my CIDR file?
Re: *Slightly OT* DNSBL Opinions.
Thanks for the pruning tips Ralf. I figured some of those were dead, just hadn't bothered to do any verification recently. Ralf Hildebrandt wrote: * Stan Hoeppner [EMAIL PROTECTED]: I highly recommend you sub to spam-l and post your question there also. http://www.claws-and-paws.com/spam-l/spam-l.html FWIW, here's my dnsbl config: reject_rbl_client zen.spamhaus.org, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client dsn.rfc-ignorant.org, That's wrong. reject_rbl_sender dsn.rfc-ignorant.org reject_rbl_client bl.spamcop.net, reject_rbl_client relays.mail-abuse.org, Dead, Jim reject_rbl_client korea.services.net, reject_rbl_client web.dnsbl.sorbs.net, reject_rbl_client relays.bl.gweep.ca, reject_rbl_client proxy.block.transip.nl, I *think* this one may be dead as well. reject_rbl_client relays.dnsbl.sorbs.net The only 2 that catch anything regularly, for me, are spamhaus and sorbs. The 2nd of these usually only catches stuff when there's a transient lookup failure to zen. The korea one stopped two spam in the last year AFAICT. I may as well remove the others... I have more success today with the standard postfix DNS and hostname checks and an IP block list than with dnsbls. Recent partial pflogsumm output summary: Client host rejected: Access denied (total: 231) cannot find your hostname (total: 97) Helo command rejected: need fully-qualified hostname (total: 37) blocked using zen.spamhaus.org (total: 57) blocked using dul.dnsbl.sorbs.net (total: 4) YMMV. P.S. I'd look into uribl and implementing your own ban list before either of the two dnsbls you mentioned. http://www.uribl.com/ Duane Hill wrote: On Tue, 19 Aug 2008, Adam C. Mathews wrote: Presenting using the following blacklists... dul.dnsbl.sorbs.net psbl.surriel.com zen.spamhaus.org These do a good job for me, but I wanted to look for opinions on a couple additional ones. Specifically look for false-positive opinions, adding additional DNS lookups isn't much concern to me. The two I am looking at are ... hostkarma.junkemailfilter.com I will give the list developer credit for the fact he/she has done research. However, the list developer has not provided any evidence as to the results or validity of using this list (even when asked for). Not to mention, I have not found anywhere on the site where it lists any price for mass-querying or any data feed service for its zone files. We purchase data feed service for SpamHaus and query an average of close to four(4) million every 24 hours. combined.rbl.msrbl.net Don't know much about this list. Perhaps someone else has feedback. -d
Re: Spam from hotmail servers - how to kill?
In this scenario you're better off trying to help others clean up their networks than to try to block or filter based on the content. As you stated, they are the Gorillas of mail and you can't really block them. So, work with them. Believe it or not, these records are published because people are behind those phone numbers and addresses. Help them to do their jobs by getting them the information they need. OrgAbuseHandle: HOTMA-ARIN OrgAbuseName: Hotmail Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: [EMAIL PROTECTED] OrgAbuseHandle: IC146-ARIN OrgAbuseName: Cox Communications, Inc OrgAbusePhone: +1-404-269-7626 OrgAbuseEmail: [EMAIL PROTECTED] Send a copy of the original email below with full headers to the above addresses. The originating client IP is in Cox's broadband cable network in Oklahoma: Name: ip68-97-155-25.ok.ok.cox.net Address: 68.97.155.25 M$ can put a hold on or disable the Hotmail account. Cox can either kill the customer if he/she is a repeat offender or assist in getting the PC cleaned up if it's a zombie infection. James Robertson wrote: Recently we noticed an increase in junk and discovered that it's coming from Hotmail (and to a lesser extent Yahoo). The problem is that these spammers are smarter that the average spammer. The don't spam flatout all the time (not to us anyway) and since the mail comes from hotmail's servers and they use a Hotmail address [EMAIL PROTECTED] then they get by Postfix and Spamassassin quite easily. I have not tested it but I would imagine greylisting would fail since hotmail's servers will do the normal thing and retry later (using same sender address etc). Most of what we have been getting is Drugs related junk so I increased the scores in Spamassassin accordingly which has helped but some still gets by based on different content in the messages and obvioulsy if they chnage tactics and start doing weight loss etc then it will probably get in. We cannot block hotmail due to valid mail coming from there. Is there a way in Postfix that could filter out this junk somehow? Below are some examples ## Microsoft Mail Internet Headers Version 2.0 Received: from mail.icfrith.com.au ([XXX.XXX.XXX.XXX]) by icfmail1.icfrith.com.au with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Aug 2008 23:59:42 +1000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icfrith.com.au (Postfix) with ESMTP id DD64D2B959 for [EMAIL PROTECTED]; Tue, 19 Aug 2008 23:59:43 +1000 (EST) X-Virus-Scanned: Debian amavisd-new at icfrith.com.au X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 required=5.31 tests=[BAYES_00=-2.599, DCC_CHECK=2.17, DRUGS_ERECTILE=0.282, HTML_MESSAGE=0.001, ONLINE_PHARMACY=0.001, TVD_VISIT_PHARMA=0.001] Received: from mail.icfrith.com.au ([127.0.0.1]) by localhost (icfsydmxg-vm.icfrith.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLdoDGWcLqRX for [EMAIL PROTECTED]; Tue, 19 Aug 2008 23:59:40 +1000 (EST) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by mail.icfrith.com.au (Postfix) with ESMTP id 00ED62B905 for [EMAIL PROTECTED]; Tue, 19 Aug 2008 23:59:34 +1000 (EST) Received: from BLU135-W36 ([65.55.116.73]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 06:59:27 -0700 Message-ID: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=_605a643e-57e1-4566-b4f5-80149ef06c75_ X-Originating-IP: [68.97.155.25] From: Nancy Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Back into the youth - only with Viagra Professional Date: Tue, 19 Aug 2008 13:59:26 + Importance: High MIME-Version: 1.0 X-OriginalArrivalTime: 19 Aug 2008 13:59:27.0695 (UTC) FILETIME=[CB5F55F0:01C90203] Return-Path: [EMAIL PROTECTED] --_605a643e-57e1-4566-b4f5-80149ef06c75_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --_605a643e-57e1-4566-b4f5-80149ef06c75_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --_605a643e-57e1-4566-b4f5-80149ef06c75_-- # Microsoft Mail Internet Headers Version 2.0 Received: from mail.icfrith.com.au ([XXX.XXX.XXX.XXX]) by icfmail1.icfrith.com.au with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Aug 2008 20:55:59 +1000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icfrith.com.au (Postfix) with ESMTP id 5A7AC2B961 for [EMAIL PROTECTED]; Tue, 19 Aug 2008 20:56:00 +1000 (EST) X-Virus-Scanned: Debian amavisd-new at icfrith.com.au X-Spam-Score: 1.728 X-Spam-Level: * X-Spam-Status: No, score=1.728 required=5.31 tests=[BAYES_50=0.001,
Re: *Slightly OT* DNSBL Opinions.
Rob McEwen wrote: Stan Hoeppner wrote: That's Rob's list, haha! It's cool to hear folks are using it. He's been plugging it on spam-l for a while. Stan, I really do like you... and I don't want to make an enemy out of you... but there are massive mis-characterizations in that statement above... to a point where I'm offended. (1) Since my original announcement about my lists (about 17 months ago!), I think I've averaged mentioning my lists on SPAM-L about once every two months... all within proper context... and about half of these in response to others bringing it up... and not at all in many, many recent weeks. Seriously, is that plugging it for a while? (you make me sound like a slimy used car salesmen and, in the context of what actually happened, I'm a little offended by that!) I'll make this brief as we're way OT for the postfix-users list and then go off list for the rest. I just want my apology to be in public, as it was not at all my intention to portray Rob as a slimy used car salesman! Plugging was a very bad word choice. To correct myself: Rob's list had been mentioned a few times on spam-l in recent months. Again Rob, I'm sorry.
Re: Am I really using a CIDR map?
Robert Lopez put forth on 4/6/2010 1:56 PM: Then then this is working: $ postmap -q 222.254.228.0 cidr:/etc/postfix/cidr-ip DISCARD $ postmap -q 222.254.228.1 cidr:/etc/postfix/cidr-ip DISCARD So, now I understand. Don't feel bad Robert. I went through pretty much the same thing you have back when I first started using CIDR maps (and many other Postfix features). Postfix documentation is not a how-to as much as it is a concise definition of each parameter. It takes a while to get used to the style and flow of the man pages before one can easily digest any given page he/she pulls up. How-to guides found via Google et al can really help you figure out your current issue, plus help you digest the man pages if you cross reference the how-to and the docs. After a while, you'll understand the terminology and way the docs work, and you'll be less reliant on the how-to's and books. Like any _technical_ document, Postfix man pages require the reader to be familiar with terminology definitions in the document. I have found that this sometimes requires backtracking through multiple doc sections just to figure out what the terms in the man page I'm currently looking at mean. Instead of man pages in a bash console, I usually use: http://www.postfix.org/postconf.5.html I use my browser's find-in-current-page function to jump up and down through this main.cf config doc to find the information I need in order to understand a given section. This is much more intuitive than jumping back and forth through multiple man pages in bash. Many things on this page are hotlinked to other relevant things on the same page which is really nice. Bookmark this page. I think you'll find it very beneficial. If you find you still can't understand something, Google it, and you'll often find something written in a way you can understand it better. I've been using Postfix since 2005. In the past five years I have learned (at least) one valuable lesson: Finding and understanding information in the Postfix documentation requires _patience_ and perserverence. ;) Someone stated yesterday or the day before that becoming a mail op isn't easy, it's not for everyone, and the good ones have spent years honing their knowledge and skills. As I stated, I've been using Postfix for 5 years, and I'm still a novice WRT most of the features. Welcome to the club. :) -- Stan
Re: RBL Usage questions
Ralf Hildebrandt put forth on 4/10/2010 2:21 AM: I'm using zen.spamhaus.org in postscreen and, reject_rbl_client bl.spamcop.net reject_rbl_client bogons.cymru.com reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_reverse_client dbl.spamhaus.org Using these dnsbls here: smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org ... I reject most spam via other methods, mostly pcre/regex and cidr tables. My dnsbl queries reject less than 1% of my spam load. Plug the following dynamic/generic rdns regex table into your Postfix configuration and see if it catches some spam for you. It does a good job here. Given its size I'd recommend running it (and all your map files) via proxymap. Ask here if you're unsure or need help implementing proxymap. It bit me the first time I tried it. smtpd_recipient_restrictions = ... check_client_access regexp:/etc/postfix/fqrdns.regexp ... /etc/postfix/fqrdns.regexp http://www.hardwarefreak.com/fqrdns.regexp This regex file is free for anyone to use if you wish to. The FP rate should be zero since it matches only dynamic/generic rdns names. -- Stan
Re: RBL Usage questions
Reinaldo de Carvalho put forth on 4/10/2010 5:56 PM:
In other words:
/([0-9]{1,3}(\.|-)){3}.*\.[a-z]+/ reject generic hostname
/(^a?dsl|a?dsl(\.|-)|(\.|-)a?dsl|(\.|-)d(yn|ip|ial)(\.|-)|(\.|-)cable(\.|-)|(\.|-)user(\.|-)|^dynamic|(\.|-)dynamic|dynamic(\.|-)|(\.|-)ppp(oe)?(\.|-|)|^ppp)/
reject generic hostname
Except these aren't fully qualified patterns, can generate FPs, and cause
other problems. The patterns I shared are fully qualified, so the chance of
FPs is zero or near zero. Also note the domain specific reject text in my
patterns.
Your patterns are what many people start out with. They may work fine for a
while on low volume vanity servers for the family and the dog, but they
don't work well on real mail streams at decent sized organizations. This
was discussed at length on spam-l not too long ago. That's how I ended up
with the regexp file I shared here, because I was previously using something
generic like that above, and a seasoned OP took pity on me (and others).
--
Stan
Re: RBL Usage questions
Noel Jones put forth on 4/10/2010 8:16 PM: On 4/10/2010 5:49 PM, Stan Hoeppner wrote: smtpd_recipient_restrictions = ... check_client_access regexp:/etc/postfix/fqrdns.regexp ... You'll probably get more hits using check_reverse_client_hostname_access. That prevents some clients from sneaking through as unknown when they don't have a matching A record. http://www.postfix.org/postconf.5.html#check_reverse_client_hostname_access I'm still on Debian Stable (Lenny) Postfix 2.5.5. When Squeeze is rolled to stable and I get Postfix 2.6.5 I'll be changing this, as well as some other parameters that are only available in 2.6+ -- Stan
Re: RBL Usage questions
Alex put forth on 4/10/2010 7:28 PM:
smtpd_recipient_restrictions =
...
reject_rbl_client zen.spamhaus.org
reject_rhsbl_client dbl.spamhaus.org
reject_rhsbl_sender dbl.spamhaus.org
reject_rhsbl_helo dbl.spamhaus.org
I'm familiar with zen, but I believe the dbl is relatively new,
correct? What other URI BL lists do people use?
The dbl is somewhat unique in that it's not just a uri domain list. It also
contains domain names that directly send spam. This is how I use the dbl.
It stops a few spam, and every little bit counts.
Can these postfix restrictions be used with older versions of postfix?
I have a few systems with older versions and can't upgrade right now.
I'm not sure about all of them. Check yourself here:
http://www.postfix.org/postconf.5.html
I reject most spam via other methods, mostly pcre/regex and cidr tables. My
Can you tell me more about rejecting using cidr tables? Do you mean
the bogon list or ASN numbers? I seem to remember a downloadable list
of the top 10 ASNs that could be used to add weight to an SA score.
I've built a cidr table over the last couple of years of mostly showshoe
networks that have spammed me. I also use ipdeny.com cidr ranges to block
all smtp connections from certain countries. The combined list is
approximately 12,000 cidr entries from /12s to /24s. In my case these are
implemented as:
cidr=cidr:/etc/postfix/cidr_files
smtpd_recipient_restrictions =
...
check_client_access proxy:${cidr}/spammer
...
dnsbl queries reject less than 1% of my spam load. Plug the following
dynamic/generic rdns regex table into your Postfix configuration and see if
But isn't it really a subset of just downloading a current zen zone
and querying against that?
I don't have data feed access to zen, so it would be impossible for me to
answer that question. Considering what the regex looks for, the only likely
overlap would be with the pbl. I've never tested the overlap. Even if the
overlap was 100%, local determination is a better solution for a number of
reasons, including response time and dnsbl query load. In my opinion, it's
better to make an accept/reject determination locally and only query a dnsbl
when a local determination can't be made. dnsbl lookups are the 2nd to the
last test in my config, greylisting being last. My MX MTA makes very few
dnsbl queries.
How do you update it? Manually? That doesn't sound feasible for a
larger network or without having some type of procedure for keeping it
updated surrounding it. What type of network do you have it running
on?
Most networks don't change their reverse naming conventions once they've
established them. Once the pattern is identified, it doesn't really need
maintenance. If an organization does add or change rdns patterns, the only
downside is you won't catch those, but you still get no FPs.
it catches some spam for you. It does a good job here. Given its size I'd
recommend running it (and all your map files) via proxymap. Ask here if
Can you include information on proxymap and postfix for me to read?
http://www.postfix.org/postconf.5.html#proxy_read_maps
I'll be nice since this bit me on the first attempt, instead of allowing you
to make the same mistake. When you modify this list by declaring it in
main.cf, you have to include the entire default list, and then add the
additional tables you want to have read via proxymap. Hence this reference
in the documentation: proxy_read_maps (default: see postconf -d output)
The postconf -d output gives you the default proxymap list. Note that the
ones I added begin with proxy:. The $(cidr) is merely a reference to a
variable I declared to shorten long lines.
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
proxy:regexp:/etc/postfix/fqrdns.regexp
smtpd_recipient_restrictions =
...
check_client_access proxy:regexp:/etc/postfix/fqrdns.regexp
check_client_access proxy:${cidr}/countries
check_client_access proxy:${cidr}/spammer
check_client_access proxy:${cidr}/misc-spam-srcs
...
This regex file is free for anyone to use if you wish to. The FP rate
should be zero since it matches only dynamic/generic rdns names.
I guess that depends on what you consider a FP, right? IOW, I'm not
currently outright rejecting mail from unknown hosts, and it's very
Is it possible to get an FP from a consumer broadband rdns? Very unlikely.
Depends on your particular MX and those people sending you email. Do you
[OT] Quoting RFC in HTML?
Thou shalt not quote RFC whilst composing in HTML or RTF!
I think that's chiseled on a stone tablet somewhere. If not it should have
been.
--
Stan
Mike Abbott put forth on 4/12/2010 8:56 AM:
+ if (in_stream == NULL) {
+/* must fail the entire transaction */
+chat_reset(state, var_smtpd_hist_thrsh);
+mail_reset(state);
+rcpt_reset(state);
+return -1;
+ }
Why no response to the client?
The function imap_open() responds to the client before it returns NULL.
in_stream = imap_open(state, url);
+ case SMTP_ERR_EOF:
+smtpd_chat_reply(state, 554 4.6.6 EOF from IMAP server);
+vstream_longjmp(state-client, SMTP_ERR_QUIET);
+break;
Why is the DSN code 4.X.X when the SMTP reply code is 5XX? Is this a
permanent or a transient error code?
It is a transient failure. The reasoning for these particular codes was
as follows. RFC 4468 section 3.2 states If the URL fetch fails, the
server will fail the entire transaction. RFC 5321 section 4.2.2 uses
code 554 for Transaction failed. And the table in RFC 5248 section
2.4 implies that a 4.6.6 is valid with a 554. If this interpretation of
the RFCs is incorrect, please propose corrected response codes.
The remainder of your feedback speaks to style and to weaknesses in the
implementation that I pointed out in the cover letter to the code
contribution. That cover letter also said:
Feel free to [...] restructure or rewrite the code as desired,
as long as you preserve our copyright. We understand that our
implementation choices may differ from yours; if you see a better way to
achieve the same goal please do adopt the better way.
Re: Patch: support BURL
Steve put forth on 4/12/2010 10:56 AM: AFAIK Outlook often saves the messages in a local Sent folder if you use Outlook as a pure IMAP client. On the IMAP server nothing gets saved. But you are right. All the other clients that I know save the message on the server or at least are able to save the message on the server. I never managed to do that with Outlook without fancy macros/rules. In Thunderbird this is user configurable, though I believe the default for IMAP accounts is to create a Sent folder on the server and save them there. In fact, TB is so flexible here that one could have a dozen IMAP accounts configured, and could save all sent item copies for all accounts in the kermit-the-frog folder in just one of the accounts, or could dedicate one account to nothing but the kermit-the-frog sent items folder. Or this folder could be a local folder. Lots of flexibility here in TB. -- Stan
Re: relay_recipient_maps question
Gary Smith put forth on 4/13/2010 7:07 PM: Currently we are using mysql plugin for this and are switching over to static files (or files generated on a schedule from the database). Anyway, looking at the docs, it says that the entry need only been found in the file to be accepted, otherwise it will be rejected. Postfix needs to know only if a lookup string is found or not, but it does not use the result from table lookup. If this parameter is non-empty, then the Postfix SMTP server will reject mail to unknown relay users. This feature is off by default. So, do I need just this format: j...@domain.tld I know some time ago someone had mentioned for the hash lookup table to work correctly it needed a key pair so I would think: j...@domain.tld j...@domain.tld Which is the proper way to do this. I know I did this a long time ago but memories fad. My intent is to rsync the source file to the postfix box, compare it to the local and if different replace local and then run postmap on the file, on a 5 minute schedule basis. Gary- All you need in the table is one fully qualified email address per line and that's it. When email arrives, Postfix checks the RCPT TO: address against /etc/postfix/relay_recipients and if a match is found Postfix then relays the message to the host specified in transport_maps as accepting mail for that TLD. -- Stan
Re: Many IP address outgoing messages
Eduardo Júnior put forth on 4/15/2010 8:04 AM: Due the high load of e-mails over my link, I want that my messages outgoing through more IPs with only postfix box. If you only have one physical link, how will sending mail from multiple IPs within the same subnet solve your link congestion problem? -- Stan
Re: block specific IP addresses
CT put forth on 4/15/2010 4:43 PM: I have several boxes that check my relay every 40 seconds to check that the server is up. After multiple attempts to get the number of checks reduced I would like the know the preferred way to block specific IP addresses in Postfix. I have no issue with checks.. but every 40 seconds is ridiculous. To accomplish the task in Postfix, blocking only SMTP connections from those IP addresses: edit: /etc/postfix/main.cf smtpd_[client/recipient]_restrictions = ... check_client_access hash:/etc/postfix/blacklist ... # [client/recipient] selection depends on whether you use the everything under smtpd_recipient_restrictions style main.cf layout. create: /etc/postfix/blacklist ... 1.2.3.4 REJECT 4.3.2.1 REJECT 3.2.1.4 REJECT ... /$ postmap /etc/postfix/blacklist /$ postfix reload Simply eh? Or to deny all port access from those IPs, if using Linux, use Netfilter: /$ iptables -I INPUT -s 1.2.3.4 -j DROP /$ iptables -I INPUT -s 4.3.2.1 -j DROP /$ iptables -I INPUT -s 3.2.1.4 -j DROP iptables inputs are non persistent across reboots. Without knowing what OS/distro you're using, I'll give generic instructions on running this at system startup instead of rc.* instructions. As root, create something like /usr/bin/load_iptables.sh and make sure the execute bit is set. #! /bin/sh iptables -I INPUT -s 1.2.3.4 -j DROP iptables -I INPUT -s 4.3.2.1 -j DROP iptables -I INPUT -s 3.2.1.4 -j DROP As root create this crontab entry usually with crontab -e @reboot /usr/bin/load_iptables.sh Now all packets from those IPs will be dropped. Hope this helps. -- Stan
Re: Many IP address outgoing messages
Eduardo Júnior put forth on 4/15/2010 4:52 PM: On Thu, Apr 15, 2010 at 6:35 PM, Stan Hoeppner s...@hardwarefreak.com wrote: Eduardo Júnior put forth on 4/15/2010 8:04 AM: Due the high load of e-mails over my link, I want that my messages outgoing through more IPs with only postfix box. If you only have one physical link, how will sending mail from multiple IPs within the same subnet solve your link congestion problem? Currently my Postfix box outgoing e-mails through only one physical link, but i have others available. A single DSL line can pump a half million messages/day. Why do you have so many outgoing messages that you're clogging your pipe? This doesn't seem like normal mail flow. -- Stan
Re: Unknown senders and spam
Alex put forth on 4/18/2010 4:45 PM: Is it possible to use maps_rbl_domains instead of reject_rbl_client here? It appears this machine has a version of postfix that doesn't understand reject_rbl_client. maps_rbl_domains (default: empty) Obsolete feature: use the reject_rbl_client feature instead. reject_rbl_client rbl_domain=d.d.d.d ... *** This feature is available in Postfix 2.0 and later. *** (emphasis mine) Your statement leads me to believe you're using a Postfix version less than 2.0. IIRC, versions less than 2.3 are no longer supported. It appears you _really_ need to upgrade Postfix on that host. And given that it's likely a distribution package, you probably really need to update the OS on that host as well. -- Stan
Re: Unknown senders and spam
Noel Jones put forth on 4/18/2010 10:55 PM: Yes, reject_unknown_client_hostname is still too strict for us. And we're very strict! I ran with this for a short while. Had problems with it rejecting Hotmail connections. And these weren't Hotmail user mails beings delivered, but responses to my spam reports coming from the Hotmail abuse dept. Had too many other legit mails refused as well. It didn't stop any more spam here than reject_unknown_reverse_client_hostname so I reverted back to the latter. -- Stan
Re: Unknown senders and spam
Alex put forth on 4/19/2010 12:11 AM: It looks like I have a big project ahead of me to upgrade. What kind of process is involved with going from such an old version to the current, independent of all the other software? Not much. Just create/modify the new main.cf and any other config files you need, possibly using data from the old files but with current parameter syntax. As always, and as stated in the list welcome message, pasting postconf -n output for us to look at would be very helpful to both the list, and thus, more importantly, to you. I'm assuming Postfix 1.x has postconf. I didn't use it back then. I was still in diapers. ;) -- Stan
Re: DNS RBL error
Ralf Hildebrandt put forth on 4/19/2010 8:29 AM: * John Peach post...@johnpeach.com: Your nslookup shows you using 207.172.3.20 as a nameserver: 20.3.172.207.in-addr.arpa name = auth1.dns.rcn.net Your ISP's nameserver. You need to run your own, so that you query spamhaus directly. They are counting all the hits from RCN. apt-get install pdns-recursor A while back I was having issues with my ISP resolvers choking on certain sending domains, so I switched to Google public DNS, which fixed that issue but broke my Spamhaus lookups. I installed pdns-recursor on my Postfix MX (Debian Lenny) and it solved all the problems. -- Stan
