Re: odd client restrictions behaviour
On Wed December 24 2008 10:30:36 Terry Carmen wrote: > I have: > > smtpd_delay_reject = yes > > smtpd_recipient_restrictions = > permit_mynetworks > permit_sasl_authenticated > reject_unauth_destination > > > smtpd_client_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination, > hash:/etc/postfix/whitelist, > regexp:/etc/postfix/spam_ip_regex, > reject_unknown_reverse_client_hostname, > reject_unauth_pipelining, > reject_non_fqdn_recipient, > reject_rbl_client zen.spamhaus.org > > which AFAIK, should reject inbound connections that do not have a > reverse DNS entry. postconf.5.html#reject_unknown_reverse_client_hostname Reject the request when the client IP address has no address->name mapping. This is a weaker restriction than the reject_unknown_client_hostname feature, which requires not only that the address->name and name->address mappings exist, but also that the two mappings reproduce the client IP address. In other words, reject only if there is no PTR for the client IP address, and do not require forward confirmation of the PTR. > However it doesn't seem to be consistant. I get a lot of these, for > example; > > NOQUEUE: reject: RCPT from unknown[218.94.129.166]: > 450 4.7.1 Client host rejected: cannot find your reverse hostname, > [218.94.129.166]; from= to= > proto=ESMTP helo= $ dig -x 218.94.129.166 [snip] ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9248 > which are properly rejected, however I also get: > > NOQUEUE: reject: RCPT from unknown[202.70.195.135]: > 554 5.7.1 Service unavailable; Client host [202.70.195.135] blocked > using zen.spamhaus.org. To resolve this issue, please call CNY > Support and ask that your IP address be whitelisted.; > from= to= > proto=ESMTP helo= lost connection after DATA (0 bytes) from > unknown[202.70.195.135] > > Shouldn't this be rejected by reject_unknown_reverse_client_hostname No. $ dig -x 202.70.195.135 [snip] 135.195.70.202.in-addr.arpa. 86400 IN PTR 219-83-128-135.static.iolnetcom.com. $ dig 219-83-128-135.static.iolnetcom.com. [snip] ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47263 > instead of making it all the way to the zen.spamhaus.org RBL, or is > the smtpd_delay_reject causing all the restrictions to execute before > rejecting the message? smtpd_delay_reject is not the issue. That just means that restrictions wait until RCPT TO before being evaluated. Happy holidays, spend them with your family, and then get back to reading those Postfix docs. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: odd client restrictions behaviour
On Wed December 24 2008 10:57:01 Terry Carmen wrote: > /dev/rob0 wrote: > >> which are properly rejected, however I also get: > >> > >> NOQUEUE: reject: RCPT from unknown[202.70.195.135]: > >> 554 5.7.1 Service unavailable; Client host [202.70.195.135] > >> blocked using zen.spamhaus.org. To resolve this issue, please call > >> CNY Support and ask that your IP address be whitelisted.; > >> from= to= > >> proto=ESMTP helo= lost connection after DATA (0 bytes) from > >> unknown[202.70.195.135] > >> > >> Shouldn't this be rejected by > >> reject_unknown_reverse_client_hostname > > > > No. > > > > $ dig -x 202.70.195.135 > > [snip] > > 135.195.70.202.in-addr.arpa. 86400 IN PTR > > 219-83-128-135.static.iolnetcom.com. $ dig > > 219-83-128-135.static.iolnetcom.com. > > [snip] > > The postifx log says: > > "RCPT from unknown[202.70.195.135]" > > Regardless of the results from dig, doesn't the above log entry mean > that postfix is unable to find an rdns entry for this IP and that No, in this case it means that forward confirmation of the PTR failed. An "unknown" host in logs is still determined the same way it always was. Suppose I'm a bad guy (not a big leap of imagination) and I owned 202.70.195.0/24. And I set the PTR for 202.70.195.135 as "security.cnysupport.com." Would you want your logs to say ... "RCPT from unknown[202.70.195.135]" ... or ... "RCPT from security.cnysupport.com[202.70.195.135]" ?? Furthermore, consider OTHER sites' logs. What would you rather us have in our logs? Some rogue sets a PTR to your domain name, and we should believe it? "Unknown" is the safe choice. Don't worry, the forward confirmation failure was logged as a warning. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Weaning myself off of procmail: .forward+tag
A long time ago, when I didn't know any better, I did a lot of work setting up procmail recipes to handle mailing list sorting and other drudgery. I had an alias, "listmail: rob0", and sordid rules did the sorting. Later, I knew a little better, and I migrated all my subscriptions to "listmail+Tag", where "Tag" is a token appropriate to the list, such as "Postfix" for this one. Then a fairly simple procmail recipe handled all my lists without any trouble (except for the occasional problem of lowercased Tag, which turned out to be automated messages from listservers, that I did not mind missing.) That was fine for awhile. In fact it still IS fine, but I figured I could do this sorting using .forward files. I figured wrong. This was my Christmas Day project. First problem: well, I thought the alias would still have the Tag extension, but no, ~rob0/.forward+Postfix was not used. According to local(8), SECURITY: "The local(8) delivery agent disallows regular expression substitution of $1 etc. in alias_maps, because that would open a security hole." Perhaps $EXTENSION is in the "etc." Next, I tried creating a system user in passwd, "listmail", with $HOME at /home/rob0/lists. I gave it the same UID as rob0. Then I saw that the $EXTENSION was coming through as noted in the logs. But again, the /home/rob0/lists/.forward+* files were being ignored. Later, I gave up and set the alias as "listmail: rob0+lists". And /home/rob0/.forward+lists seems to be honored ... sending to procmail. Sigh. postconf relevant entries: home_mailbox = Maildir/ recipient_delimiter = + /etc/passwd: rob0:x:1007:100:Rob McGeeMiniTrue:/home/rob0:/bin/bash listmail:x:1007:100:rob0 listmail:/home/rob0/lists:/bin/bash r...@miniluv:~$ v -d ../rob0 drwx--x--x 12 rob0 users 4096 2008-12-25 18:14 ../rob0/ r...@miniluv:~$ v -d lists drwxr-xr-x 2 rob0 users 4096 2008-12-25 20:15 lists/ r...@miniluv:~$ v lists/.forward+Postfix -rw-r--r-- 1 rob0 users 30 2008-12-25 15:24 .forward+Postfix r...@miniluv:~$ cat $_ /home/rob0/Maildir/.Postfix/ Did I miss something (verbose logs will be coming soon), or could the problem be the two users with the same UID? -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
[solved] Re: Weaning myself off of procmail: .forward+tag
On Fri December 26 2008 15:53:18 /dev/rob0 wrote:
> Did I miss something (verbose logs will be coming soon), or could the
> problem be the two users with the same UID?
Case-sensitivity, the $EXTENSION is lowercase.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: Second domain
On Mon January 5 2009 20:54:49 Frappy John wrote: > On Mon, Jan 5, 2009 at 9:30 AM, Tolga wrote: > > What is the directive I need to edit to have a second domain that > > accepts e-mail? > > I just add an entry to the local-host-names file. This is not good advice, because it depends entirely on non-default local settings. BASIC_CONFIGURATION_README *might* have some answers for the OP, but then, there was no context provided, so it might not. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: postfix, cannot receive email.
On Fri February 20 2009 23:25:31 Sahil Tandon wrote: > On Sat, 21 Feb 2009, post...@yeah.net wrote: > > Feb 21 11:33:21 server2 postfix/smtpd[18192]: connect from > > rv-out-0708.google.com[209.85.198.244] Feb 21 11:35:03 server2 > > postfix/smtpd[18192]: lost connection after CONNECT from > > rv-out-0708.google.com[209.85.198.244] Feb 21 11:35:03 server2 > > postfix/smtpd[18192]: disconnect from > > rv-out-0708.google.com[209.85.198.244] > > That's it? See "related" between "show" and "logs". If that's ALL the logging, it suggests a lower-level networking issue, like possibly a misconfigured upstream router. Check the router documentation and troubleshoot the networking. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Question regarding this mailing list & privacy.
On Sun February 22 2009 16:05:09 KLaM Postmaster wrote:
> Is this mailing list closed (or fairly closed), I only ask because if
> it is then there does not seem to any good reason to munge addresses,
> domain names etc.
> If it open (that is publicly readable) then there is.
http://www.google.com/search?q=klam+postmaster+%22postfix-users%22
should have your answer.
Note: munging individual email addresses is often a good idea because
of spam harvesters. Munging domain names is generally a BAD idea,
especially if the problem concerns mail routing or other features which
depend on domain names.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: Limit rate/concurrency to a given domain
On Mon February 23 2009 09:52:26 Santiago Romero wrote: > > That's right, the logs show the program name (smtp) not the > > transport name; you can't tell which transport called smtp. > > > > You can add something like > > -o syslog_name=postfix-slow > > to the master.cf slow transport entry to differentiate the logging. > > That's it. Postfix is awesome and very well designed. Such kind of > change would need 723435 patches in qmail (and that's why I'm > migrating all my qmail servers to postfix). > > Thanks a lot. To be fair, probably only 723434; qmail logging is all done to stdout, and you're free to set up any kind of filter or log preprocessor which can do what you need. You still wouldn't have the clarity and plain language information that Postfix logs offer, of course. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: alias question
gt; smtpd_tls_auth_only = yes
> > > smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
> > > smtpd_tls_key_file = /etc/ssl/private/postfix.pem
> > > smtpd_tls_session_cache_database =
> > > btree:${queue_directory}/smtpd_scache smtpd_use_tls = yes
> > > transport_maps = hash:/etc/postfix/transport
Why are you using transport_maps ?
> > > virtual_alias_maps = hash:/etc/postfix/alias-virtual
> > > virtual_gid_maps = static:5000
> > > virtual_mailbox_base = /home/vmail
> > > virtual_mailbox_domains =
> > > mysql:/etc/postfix/mysql_virtual_domains_maps.cf
> > > <http://mysql_virtual_domains_maps.cf>
> > > virtual_mailbox_limit = 0
> > > virtual_mailbox_maps =
> > > mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
> > > <http://mysql_virtual_mailbox_maps.cf>
> > > virtual_minimum_uid = 5000
> > > virtual_transport = dovecot
So, you also changed the default virtual_transport.
> > > virtual_uid_maps = static:5000
You did not set myhostname, mydomain, mydestination: common and basic
settings. Do you know what they are? I bet you don't.
> > > and log non-verbose:
snip
> > > mail2 postfix/pipe[4168]: 901AB5FAFD2:
> > > to= > > <mailto:supo...@eletricadw.com.br>>, relay=dovecot, delay=1,
> > > delays=0.98/0/0/0.04, dsn=2.0.0, status=sent (delivered via
> > > dovecot service)
This seems to have been handled as a virtual mailbox class domain.
There's no indication of a problem here. What SHOULD have happened?
Oh, I know the answer to that.
You SHOULD have read the Postfix documentation, and not that HOWTO.
;)
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: mysql lookup errors
On Mon March 2 2009 12:51:23 kj wrote: > I'm seeing this in the logs: > > Mar 2 18:18:05 web postfix/cleanup[27207]: warning: mysql query > failed: MySQL server has gone away snip > Mar 2 18:18:30 web postfix/pickup[26468]: E381E7102B3: uid=48 > from= snip > RHEL5, with the stock Red Hat rpm recompiled with mysql support. That RPM is probably chroot'ed by the distributor. My first guess is that you're seeing a chroot problem. My second guess, SELinux. In either case, seek support from your vendor for these problems. > 1. What could possibly cause postfix to have lookup problems when > nothing else does? The server did run out of disc space a few days > ago. I did a postsuper -s -v which didn't show any problems. Could > the disc space issue have damaged something? > > 2. Is there a way to enable debugging output for connections from > apache? Uh, "connections from apache", what? Is that a Postfix question? If so see postconf.5.html#debug_peer_list and list the IP address of the client. See also DEBUG_README (which will also describe the chroot issue and how to get out of it.) However, the logging in your post did not show any "connections from apache," it showed submission via sendmail(1) by your apache user. Try "man sendmail" or sendmail.1.html. > 3. I looks like the query fails when the mysql connection has timed > out. Can postfix be told to reconnect automatically instead of > accepting it as a failure? -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: alias question
On Mon March 2 2009 13:07:18 Victor Duchovni wrote: > On Mon, Mar 02, 2009 at 12:56:33PM -0600, /dev/rob0 wrote: > > Massive confusion, and looking back on the thread somewhat, I still > > think we're lacking a good description of the problem. > > > > On Mon March 2 2009 06:31:09 Leonardo Coelho wrote: > > > I'm sorry but i don't get it, if i have this two lines: > > > > local_transport = virtual > > > > Don't do this. It probably doesn't work anyway. We have address > > classes with proper *_transport defaults. The local_transport is of > > course local(8), which is designed to work with Unix users and > > traditional Unix system aliases(5). > > There is nothing wrong with "local_transport = virtual", if one wants > virtual delivery with no aliases(5) processing or .forward processing > for all local users, but often setting mailbox_transport is a better > way to handle "local" (system-user) mail. Thanks. I was thinking, as well, that the someone with such a need might do better using relay_domains and set "relay_transport = dovecot", for the domains defined in his virtual_mailbox_domains, since later on the OP also changed virtual_transport. Then the mydestination domains could be moved to virtual_mailbox_domains and mydestination unset. This fits in with the principle of doing the least possible pounding of square pegs into round holes. Of course this is all academic; I doubt the OP really knows what he needs. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: smtpd_recipient_restrictions suddenly stopping mail
On Tue March 3 2009 12:48:59 Wietse Venema wrote: > Kevin Bailey: > > Today, about 80% of emails started getting bounced back with: > > So we commented out the spamcop line... then we got > > So we commented out the spamhaus line... then we got > > Then we commented out the rfc-ignorant.org line and the mail is > > getting through. So the restrictions line now looks like: > > Looks like your DNS service is making up replies for names that > don't exist. > > This is easily verified. > > $ host -t a 27a28250f4b7c74acc01d042687e2273.com > $ host -t a 27a28250f4b7c74acc01d042687e2273.org > $ host -t a 27a28250f4b7c74acc01d042687e2273.net 0.0.0.0.zen.spamhaus.org. 150 IN A 205.234.170.218 (as seen at http://pastebin.ca/1352096 ) http://205.234.170.218/ appears to be affiliated with this outfit: http://www.dnsmadeeasy.com/ People who don't understand how DNS works, and yet think they can charge money for a DNS service ... -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Spam attacks
On Wed March 4 2009 08:48:18 Paweł Leśniak wrote: > But then we come to definition of spam. It's in simple words unwanted > message. Too simple, and not correct. The true definition of spam is UBE: unsolicited bulk email. Most spammers put out messages that a tiny percentage of recipients want to see. It's how they keep making money at it. Postmasters who fail to understand what spam is contribute to the problem, which is this: email has become nearly unusable for many people, and would be unusable for everyone without sane strategies to control the spew. I bet 95% of all SMTP traffic is abuse. > Also IMHO I'll get much more "false positives" with zen then with > authentication if for example I'd be interested in getting money and > medicines offers. We get here to definition of "false positives" > which can be very different for different customers. And that leads For the most part, I don't care what the end user thinks, for reasons implied above. If they solicited email from a legitimate (i.e., not listed on SBL and not using zombies) bulk sender, they'll get it. If they solicited email from a spammer, oops, it's blocked. We all owe it to the Internet to limit spammers' access to our clue-deprived users who might otherwise help keep them in business. I try to explain it to them. No, it's not easy. No, I am not managing any large sites at the moment, but if I was, I'd put up explanations with links on a http://postmaster.example.com/ Web site. Most people who claim that Zen gives "false positives" are not using reject_rbl_client properly. Obviously, you do not reject_rbl_client before permit_sasl_authenticated. But in your case I don't know what you're saying. I think the issue of authentication that you bring up might be irrelevant, except perhaps for the narrow "issue" of sender equals recipient. I haven't noticed a significant problem with such spam, which is probably attributable to Zen. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: That Relay Access Denied Thing
On Wed March 4 2009 08:39:37 Victor Duchovni wrote: > If I recall correctly the OP reported using Postfix 2.2 and should > see: > > http://www.postfix.org/postconf.5.html#smtpd_sasl_type > > attempts to use Dovecot SASL auth with Postfix 2.2 are unlikely to > get very far. I did it, but I cheated. I used Timo's patch. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Blocking a domain and user
Please don't top-post. Thank you. On Wed March 4 2009 17:10:49 Jim McIver wrote: > Guess I'm confused. I have a relay_recipient and recipient_access > files listing only valid user's email addresses for my company. > ie.. > relay_recipients > bg...@lmtribune.com any_value > bi...@lmtribune.com any_value > bjohn...@lmtribune.com any_value > > recipient_access > bg...@lmtribune.com permissive > bi...@lmtribune.com permissive > bjohn...@lmtribune.com permissive This sounds right. You could use the same map for both purposes. There's nothing magical about "any_value", in fact, the lookup result for relay_recipient_maps is ignored. So it might as well be "permissive" or "restrictive" or whatever. > and nothing in virtual_alias_maps. I just seem to be getting hammered > with yahoo.co.jp and wanted to block .co.jp or even .jp. > > Putting info in putting .jp in access_client, sender_access or > client_access doesn't seem to stop it. > Sorry for my lack of understanding. Show the logs for the suspicious mailq entries when they first arrived. Not the smtp(8) logs showing you being blocked by yahoo.co.jp's MX hosts. My WAG here: your Postfix configuration is correct, rejecting unknown recipients, but the @yahoo.co.jp senders originated from your own server. Compromised HTTP+PHP service? -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: OT: Diagnose blocked mail
On Wed March 4 2009 17:26:01 Ray wrote: > On Wednesday 04 March 2009 16:12:32 Terry Carmen wrote: > > Ray wrote: > > > Hello, > > > I'm having an issue with mail being blocked (I think) and I was > > > hoping that someone here would give me an idea on where to get > > > started. > > > > > > here's the situation. (Made up names) Unfortunately, made up (misappropriated) domain names as well. Your problem is most likely either broken DNS or as you suggest, some kind of firewall blocking. We can't help with any of that if you don't use real domain names. > > > server is postfix with amavis-new, spam-assassin and dovecot. > > > logs are fairly verbose. > > > > > > Alice (al...@example.com) sends Bob an Email (b...@myserver.com) > > > CC (b...@3rdserver.com) I run myserver.com. message goes through > > > to b...@3rdserver.com, but not b...@myserver.com. > > > there is absolutely no trace of alice's domain in the mail logs. > > > > > > am I being blocked up stream, is my server discarding the mail > > > somewhere or ...? > > > > > > any suggestions including alternate mail lists or google search > > > terms very much appreciated. > > > > > > Ray > > > > Post the appropriate section of /var/log/maillog showing the > > misbehaving transfer. > > > > Terry > > That's the problem, there's nothing in the logs. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: whitelist from spamhaus
On Wed March 18 2009 03:06:40 Pascal Volk wrote: > > can i whitelist one domain from checking spamhaus ? > > thanks > > smtpd_recipient_restrictions = > ... > reject_unauth_destination > ... > check_client_access hash:/etc/postfix/whitelist_clients > check_sender_access hash:/etc/postfix/whitelist_senders > reject_rbl_client zen.spamhaus.org > ... > > /etc/postfix/whitelist_clients: > mailout.trusteddoma.in OK > # or ip address of trusted hosts > > /etc/postfix/whitelist_senders: > u...@trusteddoma.in OK Some comments I would add: 1. I consider it best practice to use "permit_auth_destination" rather than "OK" for whitelisting. That's an extra safety check in case you accidentally put smtpd_recipient_restrictions in the wrong order. 2. check_sender_access is never really safe for whitelisting. Consider the common scenario of a virus on a Windows machine, sending mail purporting to be "from" the person who set up Outlook Express (or whatever they call it now) on that machine. If that spam goes direct-to-MX, it would likely be blocked by Zen. 3. If mailout.trusteddoma.in is listed in Zen, they have issues that really do need to be addressed. Are you sure you want them whitelisted? Whitelisting is a slippery slope, seldom the right answer to the real problem. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Staying on the safe side while sending mass emails
On Wed April 22 2009 17:36:56 Harsh Jain wrote: > I am choosing the following settings to be on the safe side, so as > to not get blocked by any ISP for being aggressive. I would suggest, rather, that you simply not send any unsolicited bulk email. Use industry standards for confirmation of Web or email opt-in: exactly ONE confirmation message sent per subscription request. If you do it all correctly (and maintain records of all confirmations), you're not the one to blame for delivery problems; it would be the fault of the inexperienced or incompetent or overaggressive (in filtering) site who blocks you. Of course, it's any site's prerogative to do so at any time, with or without what you might consider a valid reason. You can ask to be unblocked, but understand that it might not happen. > - We expect to deliver around 50K mails per day. That's fine, if as above, the list is clean. If it's dirty, it's probably well below what a typical spammer pumps out. > - We do not want to reattempt delivery of bounced or failed > deliveries. So your valued, confirmed opt-in subscribers are going to miss your important messages, when their MX host happens to be temporarily down or unreachable for some reason? I doubt they're going to like that, if they were, in fact, confirmed. > Please let me know if this won't affect us otherwise or any other > advice. If this doesn't hurt you, it should! > # Be Nice > default_destination_concurrency_limit = 1 > maximal_queue_lifetime = 0 > bounce_queue_lifetime = 0 > default_destination_rate_delay = 2s > default_destination_recipient_limit = 1 > default_recipient_limit = 100 -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Max Size Not Working Correctly?
On Thu April 23 2009 09:58:40 Rick Duval wrote: > > You truncated the "postfix/local" log entry so we can't see if This may be the problem. You need to use a pager or terminal which reveals the entire long line. > Is there any other log besides /etc/Postfix/maillog? That is an unusual location for a logfile. Look into your OS documentation about how they have configured your syslogd(8). -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Sizing Linux Partitions for use with Postfix
On Thu April 30 2009 10:58:17 Jon wrote: > I want to create a new debian Linux based postfix system to sit in > front of Exchange 2003 and act only as an SMTP gateway for starters > and possibly do some filtering down the road. There seems to be less > than 65,000 connections per day coming at Exchange and I'm thinking > to start with one ~16 GB disk for the system. 16GB seems very small. As cheap as storage is, why not get something with enough room for now and the future? Also, a 16GB drive is surely used, and it might not last very long. > I've read bits in the list archives that /var/queue and /var/log Which list archives? Postfix keeps its queue in /var/spool/postfix by default. Your syslogd probably uses /var/log, and yes, logging is important. > might be advisable to live on separate partitions. Digging around You don't want your queue partition/filesystem filling up. You don't want your log partition/filesystem filling up. If you make too many separations, you might eventually find that your hands are tied when it comes to dealing with new circumstances in the future. Linux LVM is probably a good idea ... on a suitably large, yet inexpensive, SATA drive. While you're at it, make it two or more drives: SATA RAID (real hardware RAID, I mean, not in-the-driver fakeraid or Linux software RAID) isn't awfully expensive either. 3ware is a good choice. I figure this: your company had the money to waste on MSexChange, so they might as well spend enough money on this hardware. The additions I've suggested probably cost far less than your license fee. > more and on the list and Internet I'm left wondering how to go about > carving up an appropriate disk layout or calculate how much I might > be safe to allocate for 'queue' for a new (low volume?) system? Is > there any wisdom anyone would be willing to share, pro's con's, etc. > to help proceed? -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Postfix Setup
l in progress! I think people like you and Scott will do fine, and I hope this helps you along your way. You're absolutely right about splitting the list; there is no way that could work. The way it works here is that any fool like me can answer a newbie's question, and if we get it wrong, we are corrected by the ones who really know. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Frequently restarting qmgr: a problem?
On Wed May 6 2009 05:02:35 Ulrich Zehl wrote: > In my setup, I have a hash table that's used in relay_domains, like > so: > > relay_domains = > hash:/etc/postfix-incoming/maps/domains, > hash:/etc/postfix-incoming/maps/auto/domains > > Currently, this table is completely rebuilt from a database every > five minutes or so, even if there are no changes. (This makes the > programm that builds it simpler.) I would suggest that you change the database query job to write to alternate files, then diff(1) against the originals and exit if no changes. make(1) and a Makefile might help automate it. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Question re: blocking unwanted senders
On Fri May 8 2009 06:38:44 Charles Marcus wrote: > I thought that since the check was under smtpd_recipient_restrictions > that all of those checks would be applied before the recipient was > 'validated'... apparently that assumption was incorrect and the > source of my problem... Well, they ARE, but you're confusing your MX host. Sometimes you tell it, "CMarcus is a valid user," other times, the opposite. There's no good way, from your end, to tell them, "CMarcus is a valid user, unless the sender is Rik." As Sahil said, the only responsible way to do this is at the edge MX, because backscatter could result. Don't make your MX host send bounces. If your provider offers this as a feature, you can do it on that end. If not, I wouldn't bother. (I wouldn't, anyway, since this does not scale well. I think it's better to deal with user/personal issues at the user level, rather than at the MTA.) > So, would moving the check above 'reject_unauth_destination' fix > this? Or is there some other way to force postfix to perform all of > these checks before validating a recipient? Recipient validation is a boolean. You're wanting to add conditions. That's probably not going to work, and it could cost you some real mail. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: private/hash
On Fri May 8 2009 10:20:22 Rocco Scappatura wrote: > I get: > > warning: connect #3 to subsystem private/hash: No such file or > directory And which process gives you this warning? You snipped out significant portions of the log, so definitive help is not possible. > In main.cf I set: > > virtual_alias_domains = domain.tld > virtual_alias_maps = hash:/etc/postfix/virtual And you're showing a main.cf snippet rather than postconf(1) output. > What is the problem? How I have to do to solve the warning in log > messages? Haven't you been through the drill before? This is not an adequate posting as per DEBUG_README.html#mail. I can guess, maybe you have a transport(5) setting. It may or may not have any relation to the virtual_alias_maps setting. Probably not, is my guess. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Urgent Postfix User Unknown issue:
On Fri May 8 2009 10:03:05 Hemanth Gopal wrote:
> Any help will be appreciated.
First, please do not top-post your replies, as it makes the list
archives much harder to follow. Consider your readers' time and
convenience to be much more important than your own.
Second, "Urgent" in the subject is IMO rather poor etiquette as per
above, because it implies that your problem is more important than the
time and expertise you are seeking here, without compensation.
Third, your question was already answered ...
> >> On Fri, May 08, 2009 at 06:55:03PM +0530, Hemanth Gopal wrote:
> >>> I am facing issue with postfix -ldap implementation that even if
> >>> i can search through ldap search given in the ldap login
> >>> credentials provided in vaccounts.cf valias.cf vdomain.cf.
> >>> Postfix still rejecting mails saying
> >>>
> >>> May 8 15:22:22 hydra postfix/smtpd[26744]: NOQUEUE: reject: RCPT
> >>> from adsl147-187.lsf.forthnet.gr[79.103.78.187]: 550 5.1.1
> >>> : Recipient address rejected: User unknown in
> >>> local recipient table;
... to which was replied by Geert:
> >> You have LDAP configured for virtual domains. The above user
> >> unknown error message is for a local domain.
> >>
> >> Local domains are listed in "mydestination", virtual domains in
> >> "virtual_mailbox_domains", check whether those lists are correct.
> >>
> >> This is documented in ADDRESS_CLASS_README.
Hemanth:
> >>> I am pasting my main.cf contents for your reference
Geert:
> >> PS: you should post complete `postconf -n` output rather than just
> >> snippets from your main.cf file.
And see, the snippet you showed us did not contain the
relevant "mydestination" setting.
main.cf:
> >>> smtpd_helo_required = yes
> >>> strict_rfc821_envelopes = yes
> >>> smtpd_recipient_restrictions = permit_mynetworks,
> >>> permit_sasl_authenticated,reject_unauth_destination
> >>> smtpd_sasl_auth_enable = yes
> >>> virtual_mailbox_base = /var/mail/vmail
> >>> virtual_mailbox_limit = 1073741824
> >>> virtual_mailbox_domains = ldap:/etc/postfix/vdomain.cf
> >>> virtual_mailbox_maps = ldap:/etc/postfix/vaccounts.cf
> >>> virtual_alias_maps = ldap:/etc/postfix/valias.cf
> >>> virtual_uid_maps = static:1001
> >>> virtual_gid_maps = static:1001
> >>> #relayhost = 0.0.0.0
The post with postconf(1) output:
> On Fri, May 8, 2009 at 7:09 PM, Hemanth Gopal
> wrote:
> > Thanks Geert
> >
> > Jamm+postfix implementation, I can search through mailboxes as per
> > ldap details in the vdomain.cf, vaccounts.cf
> >
> > r...@hydra:/etc/postfix# postconf -n
> > alias_database = hash:/etc/aliases
> > alias_maps = hash:/etc/aliases
> > append_dot_mydomain = no
> > biff = no
> > config_directory = /etc/postfix
> > delay_warning_time = 4h
> > inet_interfaces = all
> > mailbox_size_limit = 1073741824
> > mydestination = hydra.domain.com, domain.com, localhost
> > myhostname = hydra.domain.com
> > mynetworks = 127.0.0.0/8, 192.168.200.0/24
> > myorigin = /etc/mailname
> > recipient_delimiter = +
> > smtp_tls_session_cache_database =
> > btree:${queue_directory}/smtp_scache
> > smtpd_banner = $myhostname
> > smtpd_helo_required = yes
> > smtpd_recipient_restrictions = permit_mynetworks,
> > permit_sasl_authenticated,reject_unauth_destination
> > smtpd_sasl_auth_enable = yes
> > smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
> > smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
> > smtpd_tls_session_cache_database =
> > btree:${queue_directory}/smtpd_scache smtpd_use_tls = yes
> > strict_rfc821_envelopes = yes
> > virtual_alias_maps = ldap:/etc/postfix/valias.cf
> > virtual_gid_maps = static:1001
> > virtual_mailbox_base = /var/mail/vmail
> > virtual_mailbox_domains = ldap:/etc/postfix/vdomain.cf
> > virtual_mailbox_limit = 1073741824
> > virtual_mailbox_maps = ldap:/etc/postfix/vaccounts.cf
> > virtual_uid_maps = static:1001
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: private/hash
rbl_client list.dsbl.orgcheck_policy_service > inet:127.0.0.1:54000 > smtpd_sasl_auth_enable = yes > smtpd_sender_restrictions = check_sender_access > proxy:mysql:/etc/postfix/mysql-check-sender-access.cf > check_recipient_access > proxy:mysql:/etc/postfix/mysql-check-sender-access.cf > check_recipient_access > proxy:mysql:/etc/postfix/mysql-check-recipient-access.cf > strict_rfc821_envelopes = yes > transport_maps = proxy:mysql:/etc/postfix/mysql-transport.cf > unknown_local_recipient_reject_code = 550 > unverified_recipient_reject_code = 550 > virtual_alias_domains = domain.tld > virtual_alias_maps = hash:/etc/postfix/virtual -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Postfix with PostgreSQL
On Sat May 9 2009 16:31:43 Just E. Mail wrote: > This question is about installing Postfix with PostgreSQL. I am > posting on this Forum hoping that somebody has done it and help me > out. > > CentOS 5.3, PostgreSQL-8.3.7, Postfix-2.5.6 CentOS probably has PostgreSQL in their RPM repository. If so, I would recommend that you install that via RPM, and get a SRPM for Postfix. Simon Mudd has Postfix SRPMs whereby you can simply set your choices in the spec file and rpmbuild(1) it. I only ever did one RHEL machine, and it was long ago, but that is how I did it. > I have setup a PostgreSQL Server and PostgreSQL Client under DEFAULT > folders. I can connect PostgreSQL Server from PostgreSQL Client. > > Now I am trying to install Postfix on the pgsql Client machine. > Postfix has the following command to 'Building Postfix with > PostgreSQL support': > > % make -f Makefile.init makefiles \ >'CCARGS=-DHAS_PGSQL -I/usr/local/include/pgsql' \ >'AUXLIBS=-L/usr/local/lib -lpq' > > > Since I have pg Server & Client machines, I have no idea where is > '-I/usr/local/include/pgsql' & '-L/usr/local/lib -lpq'. Can somebody > help. The "local/" path element will not be correct for most (if not all) distributor-provided packages of PostgreSQL. You might, however, need to have "*-devel" packages installed. See your CentOS / RHEL documentation. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Transport Maps Ignored After Upgrade
On Mon May 11 2009 11:33:37 Eric Cunningham wrote: > I guess I'm still missing something so here's my 'postfix -n' output > and logfile showing the rejection. > >>> for postfix to accept mail for a domain (from anywhere), the > >>> domain needs to be found in one (and only one of): > >>> - mydestination (this is for mail delivered to a unix account) > >>> - relay_domains (this is for mail passed to another MTA) > >>> - virtual_mailbox_domains (this is for mail delivered to a > >>> "virtual" user) > >>> - virtual_alias_domains (this is for mail rewritten to another > >>> address in another domain) > > > > as you can see, there is no *_recipient_maps here. if you get > > "relay access denied", then the domain is not listed in one of the > > above mentioned classes. > > > > if this sin't clear, please show rejection logs (unaltered, > > unedited) as well as output of 'postconf -n' (because it probably > > changed since your last post). > mydestination = $myhostname, obtest.$mydomain, outbox.$mydomain, > mail.$mydomain, localhost.$mydomain, localhost.localdomain, > localhost, beachcomberscompanion.net, whoi.net, > oceansites.org, interridge.org > myhostname = obtest.whoi.edu ($mydomain is at the default, which should be "whoi.edu") > relay_domains = $mydomain, oceanus.whoi.edu, > atlantis.whoi.edu knorr.whoi.edu, bosun.whoi.edu, > striker.whoi.edu, striker2.whoi.edu, sssg1.whoi.edu ... > virtual_alias_domains = $virtual_alias_maps > virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap These are all your address class definitions. We can't see into your virtual_alias_maps to know what domains might be listed there. You can show us "postmap -q sanguine.whoi.edu hash:/etc/postfix/virtual" and "postmap -q sanguine.whoi.edu ldap:vldap". BTW, I always use complete paths for lookups. I think "ldap:vldap" defaults to "ldap:$config_directory/vldap", but it never hurts to be specific, so you know what you're getting. > May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT > from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1 > : Relay access denied; > from= to= > proto=SMTP helo= So, sanguine.whoi.edu is apparently not in any of your address class definitions. It doesn't matter what's in transport_maps for this. And it's HIGHLY recommended that you do NOT use transport_maps as a dual-use lookup as an address class definition, because that could cause you to accept mail that's not yours. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Transport Maps Ignored After Upgrade
On Mon May 11 2009 12:08:02 Magnus Bäck wrote: > On Monday, May 11, 2009 at 18:59 CEST, > /dev/rob0 wrote: > > [...] > > > BTW, I always use complete paths for lookups. I think "ldap:vldap" > > defaults to "ldap:$config_directory/vldap", but it never hurts to > > be specific, so you know what you're getting. > > ldap:vldap is the legacy configuration method where you'd define > variables like > >vldap_server_host = ... >vldap_search_base = ... > > in main.cf. Nothing wrong with that, but that use is deprecated. > > [...] Thanks for the correction / explanation. I guess those settings in main.cf wouldn't show in "postconf -n". On Mon May 11 2009 12:22:20 Eric Cunningham wrote: > > ... > > > >> virtual_alias_domains = $virtual_alias_maps > >> virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap > > > > These are all your address class definitions. We can't see into > > your virtual_alias_maps to know what domains might be listed there. > > You can show us "postmap -q sanguine.whoi.edu > > hash:/etc/postfix/virtual" and "postmap -q sanguine.whoi.edu > > ldap:vldap". > > Both of those postmap commands returned nothing. As expected. > >> May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT > >> from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1 > >> : Relay access denied; > >> from= to= > >> proto=SMTP helo= > > > > So, sanguine.whoi.edu is apparently not in any of your address > > class definitions. It doesn't matter what's in transport_maps for > > this. And it's HIGHLY recommended that you do NOT use > > transport_maps as a dual-use lookup as an address class definition, > > because that could cause you to accept mail that's not yours. > > Correct, sanguine.whoi.edu isn't specifically listed in any of my > address class definitions. I'm using it for testing the MX relays, > of which I have many. Yet, DNS points to you: sanguine.whoi.edu. 86400 IN MX 10 obtest.whoi.edu. obtest.whoi.edu.86400 IN A 128.128.64.226 You either need to accept that mail (as a relay domain, perhaps) or change the MX to point to a host that will. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Transport Maps Ignored After Upgrade
On Mon May 11 2009 14:45:14 Eric Cunningham wrote:
> This may be of use in my situation. Can you point me to the docs
> that explain how to configure wildcard subdomains?
postconf.5.html#parent_domain_matches_subdomains ... one way
pcre_table.5.html ... another way
regexp_table.5.html ... another (similar) way
The first one also shows how to accomplish subdomain matching in hash:
maps.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: Sending Error
On Wed May 20 2009 21:46:53 Jason Todd Slack-Moehrle wrote: > My error is: > > Delivery to the following recipient failed permanently: > > i...@wikikalendar.com > > Technical details of permanent failure: > Google tried to deliver your message, but it was rejected by the > recipient domain. We recommend contacting the other email provider > for further information about the cause of this error. The error that > the other server returned was: 550 550 5.1.1 : > Recipient address rejected: User unknown in virtual mailbox table ... > I have a file in /etc/postfix called virtual_domains that contains: ... > wikikalendar.com > > and it is referenced in /etc/postfix/main.cf at: > > virtual_mailbox_domains = /etc/postfix/virtual_domains > > I just dont see the problem, can anyone provide some advice? First, a nitpick, it sounds like you're describing a receipt error in terms of the Postfix server. Your subject implies that your Postfix cannot send mail. Second, the proper place to get the details of your problem is from your own LOGS. If it's not in your logs the problems are different and possibly worse. But this one looks quite simple, actually. You're looking at the wrong parameter. Your virtual_mailbox_domains correctly returns wikikalendar.com as one of your domains. The problem is that virtual_mailbox_maps does not list i...@wikikalendar.com. See postmap(1), the "-q" feature, to test your virtual_mailbox_maps lookup and ensure that it returns a value for i...@wikikalendar.com. See also the list welcome message and/or DEBUG_README.html#mail for suggestions on how to get the most benefit from a post to this list. See as well, VIRTUAL_README.html , which explains the issue at hand. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: 550 No such user here
On Thu May 28 2009 13:08:00 admin2 wrote:
> Okay the top 5 google hits could not answer this.
For good reason: you have not understood the issues.
> how do I place a
> bounce mail message in the /etc/postfix/virtual file? Similar to a
> sendmail virtuser file?
What is your "/etc/postfix/virtual" file? If (as I suspect) it's your
virtual_alias_maps lookup, simply DO NOT list nonexistent users in your
virtual_alias_domains.
http://www.postfix.org/ADDRESS_CLASS_README.html#virtual_alias_class
http://www.postfix.org/VIRTUAL_README.html#virtual_alias
http://www.postfix.org/postconf.5.html#virtual_alias_domains
"Those who use Google before reading the Postfix documentation, if
fortunate, end up at http://www.postfix.org/ . If not, they end up in a
jumble of bad questions, misleading or wrong answers, and outdated
information."
-- from http://workaround.org/f=postfix , the "google" factoid[1]
> postmas...@domain.org error:nouser 550 No such user here
This can be done as a check_recipient_access lookup, in cases where
there's a valid user which should be rejected for some reason. See:
http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/postconf.5.html#check_recipient_access
Actually, in general you should consult your own local copy of the
Postfix documentation before www.postfix.org., because in many cases
it's possible that new features have been added, and you might find
version-specific references confusing, or even overlook them entirely.
[1] In fact I wrote that factoid.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
[ot / EOT] Re: myhostname is different between postconf and main.cf
On Thu May 28 2009 23:21:06 Steve wrote: > way of the 1980's 'is the law' that leads to entirely useless, rude > and incorrect answers. Replied offlist. I think this thread should stop here. Thank you. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Need to create a mail dead-end or "super" catch-all
On Wed June 10 2009 17:50:34 Michael Glenney wrote: > After this message I was starting to think you were just some guy > who's screwing with me. Then I took a second and googled your name > :) I guess I'm not coming across as genuine if you feel I'm > deceiving you in some way. I'll give this one more shot and then you > can tell me to go away. You're just not understanding the problem. "User unknown in virtual alias table" means that the DOMAIN (right-hand side after the "@") is in virtual_alias_domains, but the usern...@domain (full email address) is NOT found in virtual_alias_maps. This also occurs when the virtual_alias_maps lookup RESULT is an email address in virtual_alias_domains. You CANNOT virtually alias to a virtual alias. The result of a virtual_alias_maps lookup must be a real mailbox or email address somewhere. A common misconception is that a bare username (with no @domain) is a Unix system account. That's the default, but it's not always true, depending on the value of myorigin. > Can Postfix do this?: > 1) Postfix receives message addressed to anyn...@anydomain > 2) Postfix replaces anyn...@anydomain with my corporate e-mail > address > 3) Postfix sends message to a relay Your problem seems to be that you cannot deliver to your corporate address, and the problem there seems to be that you have listed that domain as a virtual alias domain. Wietse suggested that first, you try to send mail to this address without using the wildcard virtual_alias_maps. When you can do that successfully, you can implement the wildcard. Until then, there is no point in muddying the issue! See the BASIC readme for assistance with the basic settings you need. Don't set anything that you don't understand. Don't try the virtual_alias_maps setting yet, until you have confirmed that you can send mail through your Postfix to the address you want to use for the alias. > Thanks. I appreciate you taking the time to help me out. > > MG > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. Sigh ... these disclaimers are offensive, even more so when posted on public mailing lists. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Need to create a mail dead-end or "super" catch-all
On Wed June 10 2009 18:28:44 Noel Jones wrote: > Don't bash OP too hard. He got bit by the interaction of the > default value of virtual_alias_domains = $virtual_alias_maps > and a static map in virtual_alias_maps. That made every > domain match the virtual_alias_domains lookup. > > Just a funny interaction with a seldom-used configuration. Oh yikes, you're right (as usual), I didn't think about that. Good catch! I didn't mean for it to come across as bashing the OP, my apologies if it did. (Disclaimer: um ... I *did* mean to bash him about the disclaimer ;) ) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: How to ensure that either FROM or TO is local
On Sun, Jan 03, 2010 at 09:58:15PM +1100, Barney Desmond wrote: > > mynetworks = 0.0.0.0 > This is *definitely* very wrong! smtpd_recipient_restrictions will > allow ANY client in mynetworks to relay mail to any destination. I While it was intended, no doubt, to be very wrong, it failed. Lacking a valid CIDR expression, that only matches the single IPv4 address of 0.0.0.0, which, having special meaning in networking, is unroutable. A setting of equivalent functionality is "mynetworks =". The OP would be well advised to review the BASIC_CONFIGURATION_README, listing in $mynetworks the client networks which should be allowed to relay. If the OP does not wish to allow any to relay on the basis of IP address unless using a "local sender", as the $SUBJECT suggests, the solution is pretty simple. main.cf : mynetworks = real.IP.add.ress/CIDR[, ...] smtpd_recipient_restrictions = reject_unlisted_sender, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination[, ...] > don't know if using smtpd_reject_unlisted_sender would prevent > anything going wrong here, but this is likely to make you an open > relay. If the wrong thing had been done correctly ;) I think this would have worked too, that is, if I understood the OP's goal correctly. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: header_checks problem
On Mon, Jan 04, 2010 at 09:00:25PM +0100, Ralf Hildebrandt wrote: > * Christopher Adams : > > Summary: I would like to ban an address/domain from posting to > > my system. I am using header_checks to do that. > > Why? Wouldn't check_sender_access be more appropriate? In this case, no, because the mail was submitted via sendmail(1) by UID 552. Perhaps authorized_submit_users is the best solution to the real-world problem here. Note that the OP did not describe that, so we're limited to guessing. > > /^From: testm...@library.state.or.us / REJECT A couple more comments to augment what Ralf said: first, "." is a PCRE/regexp metacharacter, as "@" is in PCRE. Those should be escaped. Second, I am not sure what happens with "REJECT" for sendmail submission; it seems to be mostly applicable in smtpd(8) context. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Confusing sasl configuration examples
On Fri, Jan 08, 2010 at 08:37:16AM -0500, Shaun T. Erickson wrote:
> Yes, this is what is shown in the SASL Howto and how I have had
> my server's submission port configured in the past.
>
> However, in the 2.6.2 postfix distribution I'm trying to configure
> now, the default definition of the submission port uses the same
> restrictions, but it applies them to the smtpd_CLIENT_restrictions
> parameter, NOT the smtpd_RECIPIENT_restrictions parameter. I'm
> trying to understand if that is just a typo in master.cf or if the
> change is legit and, if so, why.
Here's the example to which you refer:
#submission inet n - n - - smtpd
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
If you have already configured your smtpd_recipient_restrictions in
main.cf to allow SASL AUTH, this example does indeed work. It's
probably not a typo, but I agree, it can be confusing. Why do this
with smtpd_client_restrictions, and yet assume that you didn't have
smtpd_sasl_auth_enable=yes in main.cf already?
One thing I have learned in my years on this list: Wietse usually has
a reason, which might have been beyond my ability to understand. :)
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: Confusing sasl configuration examples
On Fri, Jan 08, 2010 at 10:23:38AM -0500, Wietse Venema wrote: > /dev/rob0: > > On Fri, Jan 08, 2010 at 08:37:16AM -0500, Shaun T. Erickson wrote: > > > Yes, this is what is shown in the SASL Howto and how I have had > > > my server's submission port configured in the past. > > > > > > However, in the 2.6.2 postfix distribution I'm trying to > > > configure now, the default definition of the submission port > > > uses the same restrictions, but it applies them to the > > > smtpd_CLIENT_restrictions parameter, NOT the > > > smtpd_RECIPIENT_restrictions parameter. I'm trying to > > > understand if that is just a typo in master.cf or if the change > > > is legit and, if so, why. > > > > Here's the example to which you refer: > > #submission inet n - n - - smtpd > > # -o smtpd_tls_security_level=encrypt > > # -o smtpd_sasl_auth_enable=yes > > # -o smtpd_client_restrictions=permit_sasl_authenticated,reject > > > > If you have already configured your smtpd_recipient_restrictions in > > main.cf to allow SASL AUTH, this example does indeed work. It's > > probably not a typo, but I agree, it can be confusing. Why do this > > with smtpd_client_restrictions, and yet assume that you didn't have > > smtpd_sasl_auth_enable=yes in main.cf already? > > The purpose of the submission service is to accept mail only from > authenticated clients. This, I understand. > The above submission entry implements this > particular requirement without depending on main.cf settings. This, I do not. $ /usr/sbin/postconf -dh smtpd_recipient_restrictions permit_mynetworks, reject_unauth_destination If a client from outside $mynetworks attempts to relay to external addresses, and AUTH succeeds, it passes smtpd_client_restrictions. But in smtpd_recipient_restrictions it gets "Relay access denied". It would work if either the client is in $mynetworks, or if the main.cf setting of smtpd_recipient_restrictions has had permit_sasl_authenticated added as per SASL_README. > This is done for robustness reasons. I think, as the OP noted, that the example is confusing, and should be changed as follows: #submission inet n - n - - smtpd # -o smtpd_tls_security_level=encrypt # -o smtpd_sasl_auth_enable=yes # -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Virtual reject reason
On Fri, Jan 08, 2010 at 02:33:37PM -0500, Christopher Hackman wrote: > Is it possible to customize the following error message? > > MAIL FROM: > 250 2.1.0 Ok > RCPT TO: > 550 5.1.1 : Recipient address > rejected: virtualdomain.com > > In this sanitized example, "virtualdomain.com" is just that, as is > "invalidaccount". I see "unknown_virtual_mailbox_reject_code" will > let me change the response code, but not the text. Right. A fairly straightforward (not simple, but doable) workaround is to implement a check_recipient_access lookup against your list of valid addresses. Your virtual_mailbox_maps query will not work as is, but a little bit of SQL/LDAP magic or a simple policy service could do it. Pseudocode: if domain matches virtual_mailbox_domains: if u...@domain is found in virtual_mailbox_maps: return DUNNO else: return 550 5.1.1 Your-custom-reject-text endif endif (repeat for other address classes in use) Perhaps one of the existing publically available policy servers can already do this, I don't know. Is this really worth the trouble? I would think not, but if you still want to do it, check out these references: Access controls: http://www.postfix.org/SMTPD_ACCESS_README.html http://www.postfix.org/access.5.html SQL or LDAP interaction: http://www.postfix.org/MYSQL_README.html http://www.postfix.org/mysql_table.5.html http://www.postfix.org/PGSQL_README.html http://www.postfix.org/pgsql_table.5.html http://www.postfix.org/LDAP_README.html http://www.postfix.org/ldap_table.5.html Policy service protocol: http://www.postfix.org/SMTPD_POLICY_README.html and see this for links to existing policy server projects: http://www.postfix.org/addon.html#policy -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Confusing sasl configuration examples
Bonjour mouss, On Fri, Jan 08, 2010 at 09:53:42PM +0100, mouss wrote: > /dev/rob0 a écrit : > > On Fri, Jan 08, 2010 at 10:23:38AM -0500, Wietse Venema wrote: > >> /dev/rob0: > >> The purpose of the submission service is to accept mail only from > >> authenticated clients. > > > > This, I understand. > > > >> The above submission entry implements this > >> particular requirement without depending on main.cf settings. > > > > This, I do not. > > > > $ /usr/sbin/postconf -dh smtpd_recipient_restrictions > > permit_mynetworks, reject_unauth_destination > > > > If a client from outside $mynetworks attempts to relay to > > external addresses, and AUTH succeeds, it passes > > smtpd_client_restrictions. But in smtpd_recipient_restrictions > > it gets "Relay access denied". It would work if either the > > client is in $mynetworks, or if the main.cf setting of > > smtpd_recipient_restrictions has had permit_sasl_authenticated > > added as per SASL_README. I'm still confused; the point of confusion being that of purpose and utility. Wietse said above, "The purpose of the submission service is to accept mail only from authenticated clients." Fine. But I think it's rather useless unless it enables offsite users to relay to any address, internal or external. The master.cf example does not cover this unless as I noted, the default smtpd_recipient_restrictions has been changed. I don't see much real-world use for this, assuming basically default settings, as documentation examples must. Do you? 1. An authenticated TLS client in $mynetworks can send anywhere using this example. So what? That client can do the same on port 25 without the trouble of TLS & AUTH, with default settings. 2. An authenticated TLS client outside $mynetworks can send to any local/virtual/relay domains using this example. So what? If that client can get in on port 25, it can do the same without TLS & AUTH, with default settings. > >> This is done for robustness reasons. > > > > I think, as the OP noted, that the example is confusing, and should > > be changed as follows: > > #submission inet n - n - - smtpd > > # -o smtpd_tls_security_level=encrypt > > # -o smtpd_sasl_auth_enable=yes > > # -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject I think my suggestion makes a more useful real-world submission service, that's all. Don't you allow your authenticated submission users to relay? Clearly, the OP had read enough of the documentation to understand how to make a useful submission service, else the question would never have been asked, so indeed no harm resulted from the confusion. And Wietse can take it or leave it. No reply expected nor necessary in either case, so let's move on. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: TLS - Certificate not Trusted
On Mon, Jan 11, 2010 at 11:53:35AM -0500, Noah Sheppard wrote: [attribution to Chris is missing] > > >> On Mon, 2010-01-11 at 11:04 -0500, Dennis Putnam wrote: > > >>> I want to enforce TLS but I don't care what certificate the > > >>> receiver uses. Thanks. > > >> Apart from the fact that enforcing TLS with SMTP is usually a > > >> bad idea, [..] > > Why is TLS w/ SMTP a bad idea? TLS with SMTP is a fine idea. *Enforcing* TLS with SMTP is usually a bad idea. Many sites might not support it, and if you require TLS, you cannot get their mail nor send to them. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Spam Attack on my outgoing server
On Mon, Jan 11, 2010 at 03:27:05PM -0300, Damian Rivas wrote: > I have a Postfix box basically configured to send mail from my > organization to the Internet. Today I received a warning message > telling me that the mail queue was full. Who/what sent you that warning? > It seems that some Spammer is using my server as an Open Relay, so > I used the "check_sender_access" function to only allow my domains > to send mail to the outside, but it is not working and I don't know > what to do, perhaps you can give me some tips. No evidence below suggests that you might be an open relay. LOGS! > Postconf -n output: > mynetworks = 127.0.0.0/8, xxx.xx.xx.xx/29, xxx.xxx.xx.xx/29 These are the hosts allowed to relay. Don't mung the IP addresses. They can probably be looked up anyway, using the domain names that weren't hidden (good). > relay_domains = cht.com.ar, skalbue.com.ar, ci-educ.com.ar, > hispanoamericana.com.ar, aaovyt.com.ar, consulthouse.travel, > consul.travel If this is outgoing only, why are there relay_domains ? > smtpd_sender_restrictions = permit_mynetworks, check_sender_access > = hash :/etc/postfix/sender_map, reject_non_fqdn_sender, > reject_unknown_sender_domain, permit The second "=" is not correct syntax. Except for the two reject_* restrictions, this stage does nothing. And as documented, it CANNOT permit relaying; this is controlled only in smtpd_recipient_restrictions . > sender_map: > > cht.com.ar OK > aaovyt.com.ar OK > hispanoamericana.com.ar OK > cht.tur.ar OK > consulthouse.travel OK > > If you need anything else, please let me know. A cup of tea, please. :) YOU need to stop the spam, and if you need help in determining how your system was allowing it, please see: http://www.postfix.org/DEBUG_README.html#mail -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Spam Attack on my outgoing server
On Mon, Jan 11, 2010 at 04:44:23PM -0300, Damian Rivas wrote: Noel Jones > >Post logs here if you don't know how to evaluate them. > > >My wild guess is that you have an abused web form, but check > >the logs before you go running around telling everyone your > >web server is hacked. > > Noel, it's not my web server the problem, or I guess it isn't, it's > my outgoing mail server that has the problem and it is because I'm > not finding a way to properly check my valid senders. Your guess is not correct. The logs we would need to see are ones where suspected spam arrives. You showed the ones going out, not useful at all. > In an inconming mail relay built on Postfix you can build a list of > valid recipients and reject the invalid ones. Isn't there a similar > option to validate senders? Yes, but this is not the problem you are seeing. > And, is there a way validate if that sender has come out from my > network? I was thinking in those two things to stop this. This is Postfix default behavior. > Anyway, I'm posting some logs from the mailqueue: > > > Jan 11 16:42:43 impcht3 postfix/qmgr[29558]: DC2C94D86B: > from=, size=6006, nrcpt=1 (queue active) Do you suspect this one is spam? Find when queue ID DC2C94D86B first appeared in your logs, and the correlated smtpd "Connect from" line which preceded it, or postfix/pickup line if Noel's guess was right (I bet it was.) Repeat for one or two other suspects. Post results. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Spam Attack on my outgoing server
On Mon, Jan 11, 2010 at 06:15:21PM -0300, Damian Rivas wrote:
> >> mynetworks = 127.0.0.0/8, 200.55.14.248/29, 190.210.52.88/29
>
> >These are the hosts allowed to relay. Don't mung the IP addresses.
snip
> All mailing incomes seem to come from ns1.cht.com.ar, which is a
> gateway for the internal mail server, this is by the way, where
ns1.cht.com.ar. 3600IN A 200.55.14.250
Indeed, this host is in your $mynetworks. Exclude it using the "!"
syntax, see example at postconf.5.html#mynetworks .
> they are normally sent. There were no smtpd outputs before because
> the Spam was cycling and there was no room for any new mail. (I
> deleted all the spammer mails, of course they keep coming).
Stop this at once! The ongoing abuse has probably gotten you
blacklisted. The sooner you stop it, the better your chances of
repairing the damage.
> But now, at this precise moment, I'm watching a lot of junk being
> generated on the server so, there is the source of the problem, I
> have a worm on my internal web server, no postfix issue.
Another possibility, as you mentioned that this is the gateway for
Postfix, is that it has a misconfigured firewall that is doing both
source and destination NAT of port 25 to your Postfix. I just tested
this, and was unable to connect to 200.55.14.250:25, so if that was
the case, it is probably fixed now.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: Spam Attack on my outgoing server
On Tue, Jan 12, 2010 at 11:50:19AM -0300, Damian Rivas wrote: > >Another possibility, as you mentioned that this is the gateway for > >Postfix, is that it has a misconfigured firewall that is doing > >both source and destination NAT of port 25 to your Postfix. I just > >tested this, and was unable to connect to 200.55.14.250:25, so if > >that was the case, it is probably fixed now. > > Yeah, I've figured out that the problem was a Firewall > vulnerability issue, port 25 was open to anyone. I've fixed that > and problem solved! Ha! Good work. You read the logs, identified and fixed the problem, without waiting to be given the answer. > Thanks to you all for your help and my apologies because it was not > a Postfix issue at all, No problem, I'm glad you caught it and got it fixed quickly. It's a pleasure to help those who are working to help themselves. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: multiple PTR records
On Tue, Jan 12, 2010 at 11:27:43AM -0500, Frank Cusack wrote: > After searching the mailing list (and the web in general) what I > can gather about multiple PTR records is that postfix is adamant > that hosts should not have multiple PTR records. > > Who cares? It's like saying DNS names should not have underscores > or spaces. Indeed, the DNS standards allow PTR records to coexist with other PTRs and other RR types. If you're delegated some in-addr.arpa. zones, you can in fact put any and all RR types in them. What the resolver clients may or may not do with those records is another issue altogether. Furthermore, you're not even limited to the naming of your records. If you have 2.0.192.in-addr.arpa., you can have records with any legal name: rob0.2.0.192.in-addr.arpa. wacky.2.0.192.in-addr.arpa., whatever strikes your fancy, and $INCLUDE above re: resolvers. > Yes we don't like it, but it's easy for postfix to accept and deal > with it. OTOH, it's difficult to get OTHER admins to fix their > configuration and additionally it doesn't actually create a problem > that I can see. > > I'll post my actual problem in another thread, to keep this one > focused on the policy around multiple PTR records. I don't understand. Are you asking a question about how Postfix handles the case when multiple PTRs are found for a single IP address? That was discussed here fairly recently. Or are you advocating a change in how this case should be handled? It's hard to focus on what you said when we don't know what you said. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: client disconnects at CONNECT (multiple PTR problem?)
On Tue, Jan 12, 2010 at 03:02:37PM -0500, Frank Cusack wrote: > My postfix-2.6.5 is rejecting mail from a host which has a large Not according to what we see below. "Lost connection" does not mean you rejected them. > PTR RRset -- 44 entries and large enough to require TCP. > host/dig/nslookup actually dumps core on my solaris box (looks like > the bug was fixed in BIND just a few months ago). I don't know for > sure that it is the PTR records that are causing the problem > because all I get in the log is Coincidence, I would guess. Possibly tangentially related in that this site's administrator might have tried something else that's as silly as the multiple PTRs. :) This is almost surely something at layer 2 or 3. > Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info] > connect from unknown[1.2.3.4] > Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info] > lost connection after CONNECT from unknown[1.2.3.4] > Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info] > disconnect from unknown[1.2.3.4] > > I'm not sure what part of my postfix config to even look at since > the log message is fairly uninformative. Or more importantly, how > to whitelist their MX host. (I haven't yet reviewed Victor's > recent mail on that.) Whitelisting won't keep the connection from dropping. > I tried putting then in sender_access but apparently postfix > doesn't get that far. Here are the significant parts of postconf You're using sender_access as a check_sender_access lookup (good, the name and function are related.) However, you would want to use a check_client_access lookup to whitelist a client. But see above, that won't address the issue at hand. > smtpd_data_restrictions = reject_multi_recipient_bounce permit > smtpd_helo_required = yes > smtpd_helo_restrictions = permit_mynetworks > reject_unauth_pipelining reject_invalid_helo_hostname reject_unauth_pipelining won't work here, only in smtpd_data_restrictions > reject_non_fqdn_helo_hostname > smtpd_recipient_restrictions = reject_non_fqdn_sender > reject_unknown_sender_domain reject_non_fqdn_recipient > reject_unknown_recipient_domain permit_mynetworks > check_sender_access dbm:/etc/postfix/sender_access check_sender_access looks up the MAIL FROM address (or the domain, or the localpart), see SMTPD_ACCESS_README.html and access.5.html for details. > reject_unauth_destination reject_non_fqdn_hostname > reject_invalid_hostname check_sender_mx_access > cidr:/etc/postfix/bogus_mx reject_rhsbl_sender > dsn.rfc-ignorant.org reject_rhsbl_sender bogusmx.rfc-ignorant.org > reject_rhsbl_sender zen.spamhaus.org > reject_rhsbl_sender bl.spamcop.net permit Zen and spamcop are not RHSBL services. You're bugging them with queries that will never match anything. I would suggest that you consider "reject_rbl_client zen.spamhaus.org", however. Since you munged the name/IP of the peer with which you were having problems, there's not anything more we can do here. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: client disconnects at CONNECT (multiple PTR problem?)
On Tue, Jan 12, 2010 at 03:16:53PM -0600, Noel Jones wrote: > On 1/12/2010 3:05 PM, Frank Cusack wrote: > >On January 12, 2010 2:49:32 PM -0600 "/dev/rob0" > >wrote: > >>reject_unauth_pipelining won't work here, only in > >>smtpd_data_restrictions > > > >reject_unauth_pipelining [snip] > With postfix 2.6 and newer, reject_unauth_piplining works fine in > any smtpd_*_restrictions stage. > > And like the last sentence says, with versions earlier than 2.6, > that restriction is only effective in smtpd_data_restrictions. Thanks for the correction, Frank and Noel; I was going from memory rather than consulting the up-to-date documentation. Sorry. I'll spend some time in the release notes as penance. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Convert "_" to "+" on inbound addresses
On Mon, Jan 18, 2010 at 09:12:00AM -0800, Charles Boling wrote: mouss: > > with SQL, there is no need to use pcre. just do that in the SQL > > query to avoid having to keep an external file up to date... > > ...except that the "+" (and everything between it and the "@") is > *not* actually part of the email address. Yes it is. The entire address including "+" is always looked up first, in any map type. > To use your address as an example: > > When Postfix receives an envelope for: > mouss+nob...@netoyen.net > It automatically strips the "+nobulk" and what it actually looks up > in the database is: > mo...@netoyen.net If the lookup of the entire address fails, the recipient_delimiter and all characters which follow, up to the @, are stripped, and the second lookup is done. > I assume that the "+" magic is hard-coded in Postfix, so if I [knew > what I was doing, and] were to dig out the source code, it would be > pretty simple to change it to use "_" instead of "+". If I were to > upgrade this "hack" to something more respectable, I would: >1. Create a configurable parameter, rather than hard-coding it postconf.5.html#recipient_delimiter -- you're a few years too late. >2. Allow multiple characters (so I could still use "+" as well) This is non-trivial and has been recently addressed by Wietse. Be content with the workarounds you have been offered. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: OT: Alternative for Spamassassin
On Mon, Jan 18, 2010 at 04:28:37PM +0100, Michael Reck wrote:
> Anyway, our customers complaining the usual way ( to much spam in
> my inbox...) and are not getting smarter (i don`t want to train
> SA...) so i must bear the challenge :)
Such is the story with content filtering for spam control. It's a
never-ending (nonwinnable) struggle to stay ahead of the spammers.
Fortunately there are some observations which apply:
1. Most hosts which emit spam, emit ONLY spam
2. Those few which emit some spam need to be fixed
Therefore it is reasonable to reject spamming hosts in the SMTP
connection, before DATA.
Are you using DNSBLs in your strategy? http://www.spamhaus.org/zen/
is very effective. Being that you said you're working on a large
scale, you might have to sign up for the data feed, but it will be
money well spent. And they do offer a free trial, IIRC. You can use
this restriction during the trial period:
warn_if_reject reject_rbl_client zen.spamhaus.org
then take a sample and compare against the content filter results.
reject_non_fqdn_helo_hostname is another very safe and effective
restriction. I have never personally known a true false positive,
only some reports of sites who used it wrong (applied it to their
relaying users.) My results in the past showed that it takes out
around 25% of all connections.
I take mine a bit farther, and block any HELO with no alpha
characters, including the syntactically valid bracketed IP address
HELO. A MUA might use such a HELO, so I don't apply it against my
own relaying clients. But there is no reason for a legitimate mail
server to use such a HELO; if they don't have a domain name, why
are they using email at all?
Under development in Postfix 2.7 is a new postscreen(8) daemon (the
name might change before final release), which will perform "triage"
for your real smtpd(8) processes, and will help protect against
spamming DoS.
All this stuff would be on-topic at the Spam-L list. Find out more:
http://spam-l.com/ and consider joining us. To reply to someone else
in another thread, no, we (TINW[1]) do not claim authority nor do we
act as Internet police, but we do discuss effective strategies for
spam abatement. There are strong opinions and many experienced mail
administrators and industry representatives on the list, but we do
manage to keep the discussions mostly clean and collegial.
[1] "There Is No 'We'", a nice way of saying that your server is
under your rules, and that what works well for one site might be
(and often is) totally inappropriate for another site.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: The method behind the madness
On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote: > But my primary issue is sender validation. I don't see how, > currently, to implement this as a policy daemon without re-writing > sender validation into the policy daemon. Right, IIUC what you're doing, you would have the policy daemon do this. > I don't see any way, for example, to call another policy daemon > after permit_sasl_authenticated returns "OK". Right, you would not use permit_sasl_authenticated, just have the check_policy_service in place of this. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: How to block particular outgoing mails through postfix
On Tue, Jan 19, 2010 at 11:34:13AM +0530, J. Bakshi wrote: > I am trying to drop outgoing emails having particular email-id in > its [TO] field. Say myn...@domain1.com and myna...@domain2.com, > hence any mail destined for myn...@domain1.com or > myna...@domain2.com will be dropped . To achieve this I have made a > file sender_reject with following entry > > ` ` ` > myn...@domain1.com REJECT > myn...@domain2.com REJECT "REJECT" does not mean "drop". Refer again to the actions part of the access(5) man page. Decide what it is that you really want to do. Generally, rejection is best. > and now generating the hash map by "postmap sender_reject" > > main.cf has > > ` ` ` > smtpd_recipient_restrictions = permit_sasl_authenticated, > check_relay_domains, check_relay_domains was deprecated years ago, perhaps you should (re)visit the BASIC_CONFIGURATION_README and update your configuration? > check_sender_access hash:/etc/postfix/sender_reject > ` ` ` > > After restarting the postfix I sent an email with mail command like > > ` ` ` > mail myn...@domain1.com > ` ` ` > > and the mail was delivered !!!. It should be dropped by postfix. No. There is a great deal of confusion here. First, your mailx(1) command uses sendmail(1) submission. It does not use smtpd(8), therefore no restrictions apply. Second, think about what the "sender" part of "check_sender_access" means. Does "sender" mean the address the mail is "TO"? What does "recipient" mean? IMPORTANT HINT: the "mumble" part of any check_mumble_access restriction tells you what part of the SMTP envelope or transaction is being checked. The solutions to this problem vary depending on what you think the problem is. If you simply didn't understand the above about your "mail" command, next time use a SMTP-client MUA to test smtpd restrictions. According to the incomplete information presented, the mail should possibly have been accepted by "check_relay_domains". To reject it, obviously, do not expect a check_sender_access lookup to act on a recipient address. With a check_recipient_access lookup and a SMTP-client MUA, this might have been rejected. The MUA would have seen, and perhaps presented the user, with an error message. > Have I done any mistake/wrong configuration here ? If the problem is that you have untrusted users with shell access, I strongly recommend that you remove those users. You will have much greater risks than having these users send mail as a prohibited sender address, or to a prohibited recipient. I don't think you sound prepared to handle those risks. (I don't think I am, either, FWIW.) If you do want to limit the ability of shell users to submit mail, see postconf.5.html#authorized_submit_users to block access to sendmail. There is no good way to control the addresses (sender nor recipient) used by a shell user of sendmail. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Changes in PCRE handling postfix etch vs lenny?
On Tue, Jan 19, 2010 at 07:57:02AM -0800, Harakiri wrote: > --- On Tue, 1/19/10, Wietse Venema wrote: > > > postfix/tlsmgr[23233]: warning: request to update > > table btree:/var/spool/postfix/smtpd_scache in non-postfix > > directory /var/spool/postfix > > > > See the RELEASE_NOTES file. Postfix documentation is created > > with a great deal of effort. Don't let it go to waste. > > I dont agree on this one (and this list is maybe not the right > place for this) - Right, a Debian bug/issue should be directed to the Debian people. > i expect the debian package maintainer to take > care of any needed steps during an upgrade (or installation). In reality this is very difficult. Postfix tends to handle its own upgrades (from source) pretty well, but packaging systems often encounter problems. Or maybe it is only for the users who didn't find or didn't read the packager's instructions? I don't know. > Furthermore - there is NO RELESAE_NOTES file on a debian lenny > installation of postfix. > > I have to manually install postfix-doc to find a > /usr/share/doc/postfix/RELEASE_NOTES.gz file. This is worth complaining about, IMO. If a user should make the conscious decision to not install the documentation with a given package, that's the user's fault, but the default install should provide documentation. > Same with the TLS changes i just read up. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Exchange Mailbox Folders
On Wed, Jan 20, 2010 at 01:04:11PM -0500, Brian Evans - Postfix List wrote: > On 1/20/2010 12:49 PM, Aaron Clausen wrote: > > Some anti-spam software that works with Exchange can deliver spam > > messages to a Spam folder in a user's mailbox. Is there any > > facility in Postfix to allow that? > > > Which mailbox folder mail is sent to is up to the delivery agent. > > Postfix's built in agents, local(8) and virtual(8), are > intentionally simple and have no such feature. It's easy to do with either, actually. Configure amavisd-new to tag spam with "-spam", and in Postfix: recipient_delimiter = - mydestination = example.com [ ... ] virtual_mailbox_domains = example.net [ ... ] $ postmap -q u...@example.net maptype:/path/to/virtual_mailbox_maps example.net/user/ $ postmap -q user-s...@example.net maptype:/path/to/virtual_mailbox_maps example.net/user/.Spam/ $ cat ~user/.forward-spam /home/user/Mail/.Spam/ SQL query tricks might be employed to automatically handle the case of *-s...@example.net queries, if the chosen maptype is SQL. For a hash: map, simply script the duplication of regular user entries; also add the -spam case to your new user creation routine. Note, examples in documentation of both Postfix and amavisd-new show the use of "+" as recipient_delimiter. For reasons which have been discussed on this list, the hyphen "-" is probably better in most cases. Underscore "_" and dot "." are also good choices. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: allowing outside users access to mailman lists
On Tue, Jan 26, 2010 at 10:35:23PM -0800, Jeff Weinberger wrote:
> > Wietse:
> > > > > 5.7.1 > > > > <mailto:mylist@>>: Relay access denied;
> >
> > You have not listed the domain in relay_domains,
> > virtual_alias_domains, virtual_mailbox_domains or mydestination.
> >
> > Convince yourself and examine the output from:
> >
> > # postconf relay_domains
> I did this test prior to posting. You'll see in my postconf -n
> output that:
>
> relay_domains = $mydestination, mysql:/etc/postfix/
> mysql_relay_domain_maps.cf
This looks strange. Maybe it's a matter of your MUA doing a bad job
of line wrapping, or maybe there is a space in there? If you have
"mysql:/etc/postfix/ mysql_relay_domain_maps.cf" instead of
"mysql:/etc/postfix/mysql_relay_domain_maps.cf", that could surely
explain this.
You don't need $mydestination in there, take that out. Then show us
postconf relay_domains
postmap -q
mysql:/etc/postfix/mysql_relay_domain_maps.cf ; echo $?
> I then checked with `postmap -q "maill...@lists.mylistserver.com"
> mysql:/etc/postfix/mysql_relay_domain_maps.cf` and it showed up
> fine.
Wrong query, relay_domains is a list of domains.
> There is a possibility that the MySQL query is returning a result
> that is not what postfix needs. I have perused the documentation on
> this repeatedly and found no specification as to what that query
> should return for postfix to accept the domain.
The documentation says that if you use a lookup table for this, the
lookup result is ignored. All that matters is that a result is
returned.
> I have tried it where postfix returns the domain
> ("lists.mylistserver.com" without the quotes)
"Returns"? The domain name would be the lookup key, not necessarily
the result, which per above, is ignored.
> and where it returns the value "OK" (again, without the
> quotes) and neither one works.
>
> If you can offer specifics on what that query should return, I will
> make it do so and test again.
>
> Otherwise, if the proper return value is one of those noted, I'd
> appreciate other suggestions on why this might not be working.
You munged the domain name. That's a bad idea in troubleshooting
email routing issues. If you typoed your log mung or your postmap
query, we are not seeing it, you are on your own. Your logs tell us
that the domain is not an authorized destination handled by your
Postfix. We will choose to believe your logs.
How many domains are there in this relay_domains lookup? SQL maps
make sense for large datasets which change frequently. They do not
make sense for small, relatively static lists. It also creates a
certain risk of mail loss, because class definitions are very
important to Postfix. (Mail loss such as you are seeing, for that
matter.)
So the first suggestion is to use the real domain name, direct
copy and paste from logs and command line to your list post. And the
second suggestion is to take mysql out of this, just put your list of
relay_domains directly into the main.cf file.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: a few questions around postfix as bulk mailer (NOT a spammer!!!)
On Wed, Jan 27, 2010 at 09:21:16AM -0500, Alan McKay wrote: > Does this sound right so far? No MX record for this guy? The MX is for receiving mail for a domain. You're only receiving mail from the list, to relay out, no mailboxes. This is similar in spirit to the null client example: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client > Is there a preferred way to get it to not accept unsolicited > connections? Or does this matter? I guess nobody would have a > reason to start sending it mail anyway. Spammers continually search for exploitable services on the Internet, port 25/SMTP being among the commonly attacked ones. "If you build it, they will come," a "Server of Dreams," so to speak. You should consider setting up an abuse and postmaster mailbox for this hostname. While it should be obvious to contact those at the parent domain, it wouldn't hurt. But, you don't have to receive it at the Postfix box directly; you could set it up as an alias at the existing MX host, and create the MX for this subdomain to point to that host. > Should I configure it to know about the Kerio users, just in case? While you might eventually want to convert, there's no need for this at this time. Keep it simple? > And if so, can you point me at the appropriate readme for that? So > it can just forward to the other mail server. http://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup http://www.postfix.org/ADDRESS_CLASS_README.html#relay_domain_class > Oh, one thing I should mention as well. We currently have a > program I wrote which combs the Kerio mail logs for rejects from > the nightly "alert run". This all gets logged into a database, and > we have another program that goes through the database and turns > off emails for people with a certain number of rejects. This is of > course to help prevent us from getting flagged as spammers. I > assume that with the above setup, that Postfix should keep a > similar log and all I'll have to do is tweak my program to account > for the Postfix log format (if there are differences from Kerio). > Is this a safe assumption? Postfix will log all rejections AND BOUNCE permanent errors or queue expiration ($maximal_queue_lifetime) mails. You also need some means of handling the bounces. > And finally, is there a recommended way to configure something like > this so we don't get flagged as spammers? Seriously, the main thing to avoid being considered a spammer is to not send spam! That's all about your list management practices, and has little to do with how you set up your mailer. If you are sending UBE, you will (and should be) considered a spammer. If you need help with that, the Spam-L mailing list can help: http://spam-l.com/ > The only obvious setting I see is this one : > default_destination_concurrency_limit = 5 > > What else should I be doing? Not tweaking random default settings without good cause. :) Google this mailing list for similar questions from similar bulk senders. It comes up regularly. You're probably already on feedback loops with major receivers, right? They might need to know that you're changing your mailer and source IP address. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: setting reject code to 550 for 'unknown user in virtual table map'
On Mon, Feb 08, 2010 at 01:53:03PM +1100, john egan wrote: > On Sun, 7 Feb 2010 20:49:31 -0500 (EST) > Wietse Venema wrote: > > ferriswh...@jetechserv.com: > > > i wish to change the response code for rejection of unknown > > > user from 450 to 550. all user accounts are held in dbmail and > > > the address/user maps are via pgsql queries. > > > > unknown_local_recipient_reject_code = 550 > > unknown_relay_recipient_reject_code = 550 > > unknown_virtual_alias_reject_code = 550 > > unknown_virtual_mailbox_reject_code = 550 > > > > The first step is to look at output from the command "postconf -n" snip > soft_bounce = yes That would be the cause, right there. Take this out. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Setup "SMTP authentication" and "encrypted connections (SSL)" in postfix
On Mon, Feb 08, 2010 at 10:20:39AM +, Michele Carandente wrote: > Guys may somebody confirm that with my option I can offer both > "SMTP authentication" and "encrypted connections (SSL)"? Eero already gave you this link which covers the former: http://www.postfix.org/SASL_README.html This link covers the latter: http://www.postfix.org/TLS_README.html > I'm creating a simple GUI to configure an email in this mailserver > and I guess that with that options I don't need to add in the GUI > the part for "SMTP authentication" and "encrypted connections > (SSL)"... Right? I do not understand this. A GUI for what purpose? -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
admin GUI for Postfix (was: Re: Setup "SMTP authentication" ...)
On Mon, Feb 08, 2010 at 01:33:35PM +, Michele Carandente wrote:
> I'm making a GUI to configure in an easy way my mailserver.
snip
> Do you agree?
>
> Sorry for my questions, but I'm not a big expert of postfix and
> I'm trying to understand a bit better his behaviour...
My thought is that to make a useful administrative GUI, you would
need to be a Postfix expert. And if you were, what advantage does
this GUI give you? Not much that I can see.
Typically the goal of a GUI is to put highly technical matters in the
hands of non-technical people. For email admin, I think that is a
terribly bad idea.
If someone qualified disagreed, and decided to work on making a GUI,
IMO the best possible model for it would be SWAT, the Samba Web
Administration Tool. In fact SWAT itself could probably be adapted
fairly easily.
SWAT is not a "point-and-drool" GUI. The administrator has to know
the subject, and the GUI does little to shield him/her from the
details. In fact, the best part of it is the integrated hyperlinking
to the HTML documentation.
Note, Postfix already boasts extensive HTML documentation. The hard
part is already done.
A GUI might have a handful of basic templates corresponding to
various typical roles that a mail server might need to fulfill.
But all that said, back to the question of why? Who is this going to
benefit, how? Look at "postfixadmin". That's the kind of thing which
can be put in the hands of a non-technical person, because it is not
at all what the name implies. It's a Mysql frontend for management of
IMAP user maps. You set up Postfix to work with it, then basically
leave Postfix alone.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: fatal: no SASL authentication mechanisms
On Thu, Feb 11, 2010 at 06:22:55PM -0800, Jeff Lacki wrote:
> > >> smtpd_tls_auth_only = yes
> >
> > > Do you know what this parameter setting does?
>
> After hours of digging into this, that particular message
> seems to have come up because I didnt want plaintext
> coming across in the smtp connection so I set:
>
> smtpd_sasl_security_options = noanonymous, noplaintext
>
> By having noplaintext I got the msg because my
> dovecot and SASL configs weren't setup to handle
> anything but plain and login, so...
>
> in /etc/dovecot.conf
> auth default {
> mechanisms = plain login digest-md5
> }
>
> in smtpd.conf:
Irrelevant; that is a Cyrus SASL file. You seem to have confused
Dovecot and Cyrus. Look only at the Dovecot section in the Postfix
SASL_README, and you will see no mention at all of saslauthd nor
Cyrus configuration files.
> The SASL doc didnt explain about setting up
> smtpd_sasl_security_options with noplaintext (afaik) in
> what I was reading per the mechanisms so I got lost.
SASL_README presents a basic setup of Dovecot SASL. Advanced Dovecot
features are documented at http://wiki.dovecot.org/ .
> Im just posting this for the next guy who might have
> a problem.
Let's hope he doesn't waste time on Cyrus, if he's wanting to use
Dovecot. :)
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: Blackhole Messages
On Sat, Feb 13, 2010 at 07:28:35PM +, Frog wrote: > Every now and then in the logs I see a message such as this: > > Feb 13 14:37:37 lnxsrv01 postfix/local[19279]: 6A861302508: > to=<:blackhole:@lx.x.com>, orig_to=, > relay=local, delay=0.49, delays=0.23/0.18/0/0.08, dsn=5.1.1, > status=bounced (unknown user: ":blackhole:") > > In this case it is spam that has been rejected No, it's backscatter. You accepted it, then sent a bounce. > but in almost 8 years of using Postfix I have never seen this > before. > > Here is the output from postconf -n You have munged domain names, looking inconsistent at that, so if your question pertains to mail routing, it is not possible to help you. I can guess what might have happened. You got spam for this orig_to=, and it was rewritten (perhaps by alias_maps; perhaps by virtual_alias_maps) to this other to=<:blackhole:@lx.x.com> address. That munged domain is in mydestination (although your munging did not show that), and there's no local user nor alias called ":blackhole:". Why this ":blackhole:" result? You'd have to tell us. > alias_maps = hash:/etc/aliases > mydestination = xxx.xx.com, localhost.xx.com, , > localhost > myhostname = xx.xx.com > myorigin = /etc/mailname > sender_bcc_maps = hash:/etc/postfix/bcc > virtual_alias_maps = hash:/etc/postfix/virtual > Any assistance greatfuly appreciated The problem description was inadequate, but I left in the possibly relevant postconf lines. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Restrictions on localhost
On Sat, Feb 13, 2010 at 11:36:22AM -0500, Alex wrote: > I have a Linux server running an older version of postfix and > webmail for users to send mail. Since localhost is trusted in > $mynetworks, a connection from there can send mail to any > recipient. Since squirrelmail connects directly to localhost, > any mail that it sends is authorized. Squirrelmail might not be connecting to localhost at all. The more likely default is that it uses sendmail(1) submission. That is an all-or-nothing proposition; sendmail either takes what a given user (in this case, your Web server's process UID) gives it, or it takes nothing at all. See: http://www.postfix.org/postconf.5.html#authorized_submit_users http://www.postfix.org/sendmail.1.html > How can I add restrictions on localhost, despite it being > authorized, from sending mail as certain users or to certain > recipients? It is probable that the eventual solution to whatever problem you encountered will be found within Squirrelmail, off topic here. You could force the use of SMTP, and force authentication, and use restriction classes and smtpd_sender_login_maps. I do not know if Squirrelmail is capable of per-user AUTH. The Postfix part of it is documented: http://www.postfix.org/SASL_README.html http://www.postfix.org/RESTRICTION_CLASS_README.html http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: how to deny mail from specific domain
Ahh, someone here today with a Postfix question, not a Cisco one! ;) On Mon, Feb 15, 2010 at 12:57:40PM +0200, Aggelos wrote: > I want to deny incoming mail from domain blu0.hotmail.com. "From domain" means what? Sender addr...@blu0.hotmail.com ? > I have put in /etc/postfix/sender_access the following line: > blu0.hotmail.com554 Spam is not welcome > > and then I run > postmap /etc/postfix/sender_access Is there something magical about this /etc/postfix/sender_access filename that you are not telling us? > and > postfix reload > > Is that enough? Not even close. You must first understand how Postfix smtpd(8) access restrictions work. See: http://www.postfix.org/SMTPD_ACCESS_README.html as a starting point. Since the text of your rejection implies that spam is the problem you're trying to address, you really need to understand more about spam and spammers, too. Here is a good overview: http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: rbl sites
On Fri, Feb 19, 2010 at 11:51:22AM -0800, brian moore wrote: > "Jon L Miller" wrote: > > Is there a preferred list of rbl sites one can use in postfix. > > I keep getting the following on the following: > > Since others answered your error message, I'll answer the first > question: snip > See http://barracudacentral.org/rbl > > This is a very effective filter run by a commercial entity (ie, > Barracuda, the people who make and sell spam filtering appliances), > so they have a name and reputation to protect. (Ie, it's not just > some pissed off admin that blocks all of 12.0.0.0/8 because AT&T > sucks...) Whilst the above sounds a bit like a straw-man argument condemning other DNSBLs (I'll get to that in a bit), it does bring up a very important point, which, given the OP's post in the other thread, needs to be emphasized. Apparently Jon googled and found someone's old list of anti-spam settings. BAD IDEA when you just copy something like that. You should know every list's listing and delisting policies. If those are not acceptable to you for any reason, it is not safe to use that DNSBL for blocking of mail. You should keep informed about any DNSBL service you want to use. Many of them have mailing lists for announcements. If so, subscribe. Use of a DNSBL means you are delegating control of who can send mail to you to a third party. Don't get me wrong, that's not a bad thing by any means; it's a necessity for most sites by now. But you owe it to your users to know something about that third party. Obviously, Jon knew nothing about ORDB nor about DSBL. Now, the straw man. Perhaps it was not intended, but it sounded like a veiled criticism of other public DNSBLs. In fact all major DNSBLs are concerned about their reputations. They don't become a major DNSBL service by blocking all of 12/8 because AT&T sucks. I'll go on to share my own thoughts. There is Spamhaus, and there are others. An essential tool. Spamhaus Zen is so widely used as to make the concept of "false positive" irrelevant. If any site gets listed by Spamhaus, it cannot afford to ignore that fact. They're not likely to single you out for their complaints, because they will be having delivery problems just about everywhere. :) Spamhaus got to this position by being careful and conservative. Consequently, people who desire more aggressive blocking which can include some "human shields" as "collateral damage" will be a bit disappointed. But it can easily block 70-95% of your spam. See http://www.spamhaus.org/zen/ for more. Others that I would consider worthy of a look include NJABL (part of which is in Spamhaus XBL) and Spam-eating monkey. SORBS is a bit more aggressive, and will not hesitate to list the outbound relays of major sites when spamtraps are hit, as happens regularly. A careful site might want to try it in "warn_if_reject" mode before going live. Like Spamhaus and NJABL, there are special purpose lists served by SORBS. Spamcop is mostly automated, so, like SORBS, it's not unusual that major freemail providers are listed. CBL deserves a mention, although I never use it directly. It's the major part of the Spamhaus XBL. This one does get occasional "false positives", in that a virus-spewing site which also has real mail can get listed. See above about complaints, you are not going to be the only one blocking these "false positives". I'm not comfortable with the term, "false positive," in case you wondered about the quotation marks. It's not false if listing criteria were met. Cases in which something is listed without having met the listing criteria are extremely rare. Most of this is offtopic here, BTW. Anyone who's serious about blocking spam might want to consider joining Spam-L: http://spam-l.com/ -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Postfix Virtual Users with maildrop
On Fri, Feb 19, 2010 at 07:32:27PM +0100, mouss wrote:
> Wietse Venema a écrit :
> > Emre Yazici:
> >> I want to is to dynamically set corresponding user so that
> >> Postfix can invoke maildrop with that user's permissions and
> >> mail delivery be made with the correct user rights.
> >
> > Use the Postfix local(8) delivery agent, and execute the maildrop
> > command via the mailbox_command (or mailbox_command_maps)
> > mechanism.
>
> alternatively, make sure maildrop is setuid (isn't this the
> default?) and run it as a "trusted user" (the list of trusted users
> is configured at maildrop build time). check maildrop docs.
Another alternative to consider, since the mailbox scheme seemed
pretty simple, is to use virtual(8) with virtual_{gid,uid}_maps
populated as needed and desired. A simple scheme might be to use a
common group for all (such as "virtual_gid_maps=static:vmail") with
separate UIDs per domain.
A more complex approach can be done, such as separate UIDs per
mailbox, and a shared GID per domain. Then you have to create your
maildirs with correct ownership when creating a new account.
> That said, I prefer Wietse suggestion...
I do too, except I don't see the need for maildrop in this scenario.
Looks like a job for local(8) on its own.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: rbl sites
On Fri, Feb 19, 2010 at 06:20:27PM -0700, LuKreme wrote: > On 19-Feb-2010, at 12:51, brian moore wrote: >> so they [Barracuda] have a name and reputation to protect. > > Heh. Sorry, but this make me laugh. Ha, yes, indeed they have a sordid past, but I think they're doing better now. I have not used the Barracuda RBL yet, but from Brian's and other reports, I think it is one worth considering. Fair enough to expect them to give back to the community after all the backscatter they have spewed at us. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Some questions about logging
On Tue, Feb 23, 2010 at 01:23:08PM +0100, Borja Marcos wrote: > I'm enhancing a program I use to follow Postfix logs in sort of > real-time. It does a couple of things, and the most important is to > record a single-line summaries for each message, storing source IP > address, from, to, timestamp, size, final delivery destination > (mail relay or mailbox) and status. You can trivially have smtpd(8) help you substantially. smtpd will log everything it has regarding a message (everything before final delivery) with one simple restriction: smtpd_end_of_data_restrictions = check_recipient_access static:warn End of data was chosen because at that time the actual message size is known. Recipient access was chosen because it gives a separate entry per recipient of a multiple-recipient message. Salt to taste, enjoy. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: rbl sites
On Tue, Feb 23, 2010 at 09:40:47AM -0800, brian moore wrote: > Strip out the commas to make the sentence simpler: > Use of the Spamhaus DNSBLs by organizations and networks ... or > by ISPs ... requires a subscription to the Spamhaus DNSBL > Datafeed Service... > > When Spamhaus switched to this model, they sent mail insisting I > pay, so they seem to agree with my interpretation. > > [Ironically, the ISP's are actually owned by a Non-profit, and one > is a non-profit itself, using revenues from paying customers to > subsidize low income access... but 501c3 status is not mentioned as > a distinguisher between commercial and non-commercial, and it is > all a very complicated arrangement to appease the IRS anyway...) It's not surprising that Spamhaus would fail to mention US IRS classifications of status, since they are based in UK. Did you reply to the email and ask? When my friend[1] Norman De Forest passed away in 2006, Spamhaus donated a data feed to his ISP, Chebucto Community Net, as a memorial. There are human beings behind Spamhaus; perhaps you can find a sympathetic ear. Can't hurt to ask, anyway. Good luck. [1] An Internet acquaintance only, but I think anyone[2] who came in contact with Norman thought of him as a friend. http://beacon.chebucto.ca/Content-2006/norman.html [2] Except for spammers, of course. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Mail Transport Unavailable
Please do not top-post your replies. Thank you. On Tue, Feb 23, 2010 at 09:17:35AM -0800, motty cruz wrote: > FreeBSD 7.2 and Postfix 2.6.5 and I want to send email to myself > mo...@domain.com Please use example.com for examples. Example.TLD is reserved for examples in every top-level domain. However, it's possible that munging your domain name will make it impossible for others to assist in solving your mail routing issues. > so I type the following in the command prompt > > Filter # mail -v mo...@domain.com > Subject: test postfix conf > debug_peer_list = 127.0.0.1 In addition to what Victor said, I would point out that your mail(1)/mailx(1) client is probably not making any network connections. The debug_peer_list is not relevant for sendmail(1) submission. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: spamhaus dbl implementation
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. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Postfix Configuration to Allow Other Network Systems to relay through It
On Thu, Mar 04, 2010 at 05:44:21PM -0800, bruce wrote: > System A has postfix, and can relay successfully email through > Gmail. > System A is 192.168.1.56 > System B is 192.168.1.59 > > System B has Postfix, and has the line > relayhost [192.196.1.56]:25 1. Seems strange that you would need two MTAs at this site; it is obvious that you don't have much volume if you're relaying through gmail. 2. "man 5 postconf" and pay attention to syntax. There is no "=" in what you're showing us here. > I'd like to be able to have System B, relay it's mail through the > configured Postfix on System A. > > When I simply try on System B, to send an email, I get a > "Connection Refused:" err in the log file of System B. We can't help you unless you SHOW US these logs. > The docs imply that the Postfix on System A should be "open" to > connections from other systems in the same 192.168.1.x subnet. > There is a "mynetworks" line that's set to its default. Oxymoron there: if there is a mynetworks line in main.cf, mynetworks isn't at its default. > Is there something else I missed on this. The list welcome message and DEBUG_README.html#mail which tell you how to ask questions here which can be answered. Since B is the one with the problem, we'd want to see B's logs and "postconf -n". But it wouldn't hurt to also see what A has in its postconf output: my WAG here would be that inet_interfaces is set. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: reverse dns fails with multiple domains
Top-posting fixed. Please don't top-post here, thanks. > - Original Message - From: "mouss" >> 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. On Sat, Mar 06, 2010 at 11:18:32PM +0100, John WInther wrote: > 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?. Of course it's possible, just as Mouss said. Have the ISP set your custom reverse name (PTR) for your IP address. Use that name, whatever it was that you decide on, as $myhostname in Postfix. If the ISP can't/won't do that, you can't run a serious MTA there. Use a relayhost or shop around for other options. Hobbyists might find a VPS hosting service like Linode.com to be more affordable than business-class Internet service. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Spam to a "submail" via recipient_delimiter
On Mon, Mar 08, 2010 at 12:12:39PM +0100, postfix-us...@tja-server.de wrote: > I would like to reject any mail to "user@..." as early as > possible while still allowing mail to any other "user.s...@..." > or "u...@...". > > So far, i could only find "check_recipient_access" that points > to a file contains addresses to be rejected. > But as far as i can tell, this is already quite late in > processing the mails! Why do you think so? Put your check_recipient_access lookup as the first lookup in your restrictions list. It can come either before or after restrictions which permit your users to relay, at your discretion. For example: main.cf :: ... smtpd_recipient_restrictions = [ ... ] check_recipient_access hash:/etc/postfix/recipient_access reject_unauth_destination[, ... ] ... recipient_access :: user@example.com REJECT go away spammer > Is there any other way to reject/tarpit such "sub-mail-addresses" > (from recipient_delimiter) very very early in processing the mail? > > At best, directly after reading the first header-line ... The example I gave happens before DATA; there are no headers to read at this point. Headers are not used for mail routing. > Thank for any hint! See these for more: http://www.postfix.org/SMTPD_ACCESS_README.html http://www.postfix.org/access.5.html http://www.postfix.org/postconf.5.html#check_recipient_access -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Weird problem with virtual aliases. Error user has moved to...
On Mon, Mar 08, 2010 at 08:51:31AM +, Jaroslaw Grzabel wrote:
> I've just noticed that the one alias I've had suddenly stopped
> working from unknown reason. I'm using MySQL to keep all domains,
> users and configuration for them and when I send an email to an
> alias it bounces back with error:
> : User has moved to ja...@meil.me
> It's been working for ages and suddenly stopped. Any ideas ?
There is no way to help you with this unless you post the actual
logging and other necessary information ("postconf -n", to start,
from which point we can probably tell you what postmap -q queries
you will need to look at and correct) as was requested in the list
welcome message and here:
http://www.postfix.org/DEBUG_README.html#mail
My WAG here would be that you set relocated_maps:
http://www.postfix.org/postconf.5.html#relocated_maps
but it could be a lot of other things, too.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: Spam to a "submail" via recipient_delimiter
On Mon, Mar 08, 2010 at 02:33:37PM +0100, postfix-us...@tja-server.de wrote: > /dev/rob0 wrote: > >>But as far as i can tell, this is already quite late in > >>processing the mails! > > > >Why do you think so? > > I seem to remember, that the recipient code technically is > called later - after all headers and maybe even data has been > read by the server. > > I would like to reject those mails as soon as possible and > thought, this requires a different place. Headers *are* DATA, in SMTP terminology. Some headers are added by your Postfix, but most of them should have been received from the client. smtpd_mumble_restrictions happen at the SMTP command indicated by "mumble", with exceptions: smtpd_client_restrictions at the initial TCP connection smtpd_helo_restrictions at the EHLO/HELO command smtpd_etrn_restrictions at the (rarely used) ETRN command smtpd_sender_restrictions at the MAIL FROM: command smtpd_recipient_restrictions at the RCPT TO: command smtpd_data_restrictions at the DATA command smtpd_end_of_data_restrictions at the "." at end of DATA Exceptions: smtpd_delay_reject (default "yes") causes "mumble" == client, helo and sender restrictions to be evaluated at RCPT TO:. (There are reasons for this default setting, see http://www.postfix.org/postconf.5.html#smtpd_delay_reject for that, and search list archives if interested.) Only smtpd_end_of_data_restrictions would have access to headers, except as previously mentioned, those headers are irrelevant in normal routing and access control decisions. See these: http://www.postfix.org/BUILTIN_FILTER_README.html http://www.postfix.org/header_checks.5.html if you're interested in access decisions based on headers, but be forewarned, it's weak and usually not a good idea (most people who think header_checks(5) are the answer have been asking the wrong question.) Also note that these header_checks are implemented by the cleanup(8) daemon, not by smtpd(8). > Thanx for your hint! You're welcome. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Weird problem with virtual aliases. Error user has moved to...
On Mon, Mar 08, 2010 at 02:52:25PM +, Jaroslaw Grzabel wrote:
> /dev/rob0 pisze:
> >There is no way to help you with this unless you post the actual
> >logging and other necessary information ("postconf -n", to start,
> >from which point we can probably tell you what postmap -q queries
> >you will need to look at and correct) as was requested in the list
> >welcome message and here:
> >http://www.postfix.org/DEBUG_README.html#mail
> >
> >My WAG here would be that you set relocated_maps:
> >http://www.postfix.org/postconf.5.html#relocated_maps
> >but it could be a lot of other things, too.
>
> Yes,
>
> Forgive me this. I thought it would be rather obvious :).
People commonly seem to think so. I have no idea why that is. I do
remember not having much understanding of Postfix, but I do not
recall thinking that it must be simple.
> But...
>
> postconf -n
> local_recipient_maps = $alias_maps $virtual_mailbox_maps
> unix:passwd.byname
> local_transport = virtual
Ugly! Do not mix classes like this.
http://www.postfix.org/ADDRESS_CLASS_README.html
Define your local domain class in mydestination (and take out the
above), and define your virtual mailbox class here:
> virtual_mailbox_domains =
> mysql:/etc/postfix/mysql_virtual_domains_maps.cf
Continuing on, I see that you're using a non-default:
> virtual_transport = maildrop
If I was going to do that, I'd still leave standard classes alone.
The relay domain class (defined by relay_domains) would be a good
choice for the domains you want to handle with maildrop. You would
simply set a transport for each such domain and/or recipient in
transport_maps; no need to override the default relay_transport.
Anyway, as per my WAG, this is probably where your issue lies:
> relocated_maps = mysql:/etc/postfix/mysql_relocated.cf
postmap -q problem.addr...@example.com mysql:/etc/postfix/mysql_relocated.cf
This is probably returning the address you saw in your "user
relocated to ..." error.
Do carefully note the double use of the word, "probably". After I
advised you what we would need to see, you still have failed to post
the relevant logs.
> smtpd_banner = Sun Microsystems
This is broken and non-compliant. Don't tinker with default settings
if you don't understand them.
> transport_maps = mysql:/etc/postfix/mysql_transport.cf
Most sites don't need transport_maps. Typically they're needed to
override DNS for mail routing for relay_domains, as I recommended
above. But you're not using it as I recommended, leading me to
wonder, why DO you have transport_maps set? And a SQL map at that?
All in all, it looks like a lot of cruft and poorly understood
settings, possibly an amalgam of more than one HOWTO, each one likely
being deficient in its own way. And as over-complicated as your
Postfix is, it is still quite possible that I guessed wrong about
relocated_maps.
> File /etc/postfix/mysql_virtual_alias_maps.cf
> user = user
> password = password
> dbname = dbname
> query = SELECT destination FROM postfix_alias WHERE alias = '%s'
>
> That query returns valid email address so mine.
Probably not relevant to the problem which brought you here.
> Thank you for your help.
Again, if you do not provide the needed information, specific help is
impossible. But if I guessed right, and if you understand and fix or
remove your relocated_maps, it should not be necessary to continue
this thread.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: Weird problem with virtual aliases. Error user has moved to...
On Mon, Mar 08, 2010 at 05:17:53PM +, Jaroslaw Grzabel wrote: > /dev/rob0 pisze: >>> local_recipient_maps = $alias_maps $virtual_mailbox_maps >>> unix:passwd.byname >>> local_transport = virtual >> >> Ugly! Do not mix classes like this. >> http://www.postfix.org/ADDRESS_CLASS_README.html >> Define your local domain class in mydestination (and take out the >> above), and define your virtual mailbox class here: >> >>> virtual_mailbox_domains = >>> mysql:/etc/postfix/mysql_virtual_domains_maps.cf >>> > I fixed that as you suggested. Oops, sorry, perhaps I wasn't clear that the comments not related to your immediate problem were intended as general comments, not as "do this" advice in the context of this thread. Your extremely complex setup is also extremely fragile. >> Anyway, as per my WAG, this is probably where your issue lies: >>> relocated_maps = mysql:/etc/postfix/mysql_relocated.cf >>> >> postmap -q problem.addr...@example.com mysql:/etc/postfix/mysql_relocated.cf >> >> This is probably returning the address you saw in your "user >> relocated to ..." error. >> > Yes it returned that email address. But when I removed > relocated_maps it bounces back with: > user unknown. Command output: Invalid user specified. You broke something in the pipe command. >> Do carefully note the double use of the word, "probably". After I >> advised you what we would need to see, you still have failed to post >> the relevant logs. >> > Mar 8 16:59:25 [postfix/cleanup] 6F9442E60FD: > message-id=<20100308155925.6f9442e6...@hostname> I recently saw someone else using this type of syslogd, and I say, I do not like it at all. My syslogd (the Linux one ported from old BSD code, not sure where it's hosted) gives the PID of each logging process, and in the case of Postfix, sometimes that is very important. Oops, that's just a rant, not a suggestion that you personally change your syslogd. :) The PID is not important here, this time. > Mar 8 16:59:25 [postfix/qmgr] 6F9442E60FD: > from=, size=278, nrcpt=1 (queue active) > Mar 8 16:59:25 [postfix/pipe] 6F9442E60FD: to=, > orig_to=, relay=maildrop, delay=0.04, > delays=0.02/0.01/0/0, dsn=2.0.0, status=deliverable (delivers to command: > /usr/bin/maildrop) Postfix delivers to maildrop via pipe(8). I don't know if that is what was intended or not. This just says "status=deliverable", not actually delivering to/through maildrop. > Mar 8 16:59:25 [postfix/qmgr] 6F9442E60FD: removed > Mar 8 16:59:28 [postfix/smtpd] 6D1912E60FD: client=X[XXX] > Mar 8 16:59:28 [postfix/cleanup] 6D1912E60FD: > message-id=<4b952006.7060...@x> > Mar 8 16:59:28 [postfix/qmgr] 6D1912E60FD: from=, size=818, > nrcpt=1 (queue active) > Mar 8 16:59:28 [postfix/smtpd] disconnect from X[X.110] > Mar 8 16:59:28 [postfix/pipe] 6D1912E60FD: to=, > relay=maildrop, delay=3.1, delays=3.1/0/0/0.03, dsn=5.1.1, status=bounced > (user unknown. Command output: Invalid user specified. ) Unfortunately, when the actual delivery is attempted, maildrop does not know what to do with it. It's not logging here, and even if it was, I've never used maildrop, so I can't help with that. (It's off-topic here, as well.) > Mar 8 16:59:28 [postfix/cleanup] 7C78B2E6114: > message-id=<20100308155928.7c78b2e6...@hostname> > Mar 8 16:59:28 [postfix/qmgr] 7C78B2E6114: from=<>, size=2654, nrcpt=1 > (queue active) > Mar 8 16:59:28 [postfix/bounce] 6D1912E60FD: sender non-delivery > notification: 7C78B2E6114 > Mar 8 16:59:28 [postfix/qmgr] 6D1912E60FD: removed > Mar 8 16:59:29 [postfix/smtp] 7C78B2E6114: to=, > relay=newmail.X[X.110]:25, delay=0.72, delays=0.01/0.02/0.28/0.41, > dsn=2.0.0, status=sent (250 ok 1268064272 qp 32176) > Mar 8 16:59:29 [postfix/qmgr] 7C78B2E6114: removed > > When it used relocation maps: > Mar 8 15:46:36 [postfix/smtpd] connect from X[X.110] > Mar 8 15:46:36 [postfix/cleanup] B23092E60FD: > message-id=<20100308144636.b23092e6...@hostname> > Mar 8 15:46:36 [postfix/qmgr] B23092E60FD: > from=, size=278, nrcpt=1 (queue active) > Mar 8 15:46:36 [postfix/pipe] B23092E60FD: to=, > orig_to=, relay=maildrop, delay=0.04, > delays=0.02/0.02/0/0, dsn=2.0.0, status=deliverable (delivers to command: > /usr/bin/maildrop) > Mar 8 15:46:36 [postfix/qmgr] B23092E60FD: removed > Mar 8 15:46:39 [postfix/smtpd] AFDD92E60FD: client=X[X.110] > Mar 8 15:46:39 [postfix/cleanup] AFDD92E60FD: > message-id=<4b950ef5.9030...@x> > Mar 8 15:46:39 [postfix/qmgr] AFDD92E60FD: from=, size=819, > nrcpt=1 (queue a
Re: deleting particular msgs
On Tue, Mar 09, 2010 at 12:12:42PM -0600, Jay G. Scott wrote: > i'm trying to convert from sendmail to postfix. Welcome. > i have a utility (let's call it) that looks through files > in the sendmail mail queue and determines whether the msg is a > bounce message that i don't really want to send out. i stop > sendmail, then delete the q and d files, and restart sendmail. > > what i need is a way to delete a particular msg in > postfix's queue. ISTM that a better approach is to reject the mail that causes these bounces, *before* it gets into the queue. Typically, your recipient validation in smtpd(8) is what does this. > on my test boxes i don't have any files in the > queues -- the queue is empty. i expect i'll have some once > i go to production. Why? http://www.postfix.org/ADDRESS_CLASS_README.html (and your own local copy of the same documentation) describes the various address classes, and how they are defined, and how they validate recipients. If the problem is something else, you'd have to describe what these bounces are, in order to get good suggestions on how to fix the problem ... the REAL problem, not the symptom of deleting bounces from the queue. > but, just so i can be somewhat prepared, how do i > do this? i don't want to delete all the msgs, i can already > find ways to do that. i want to delete particular messages. > this has to be an old issue but my searches are coming up with > complete wipeouts. > > i see the postqueue command, but i also have stuff that > looks inside the message for particular things i must stop going > out. postqueue won't show me that stuff. so, is there a way to > pillage the queued files? It's basically simple for awk(1), python(1), or your preferred scripting language to parse mailq(1) output and feed results to postcat(1). But I'm hoping you're not reimplementing a broken Sendmail system as a broken Postfix one. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Bounced mails
On Fri, Mar 12, 2010 at 12:47:45AM +0100, Sam Przyswa wrote: > Is it possible to accept and send in a default mail adddress all the > mail rejected for User unknown ? Commonly referred to as a "catchall address", this is a bad idea. It *will* be abused by spammers, and it must be monitored to be sure that small typoes do not cause lost mail. For local(8) delivery, see: http://www.postfix.org/postconf.5.html#luser_relay For other address classes, the table lookup key is "@domain" as per: http://www.postfix.org/virtual.5.html http://www.postfix.org/postconf.5.html#relay_recipient_maps http://www.postfix.org/postconf.5.html#virtual_mailbox_maps -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: reroute mail based on headers
On Wed, Mar 17, 2010 at 05:09:00PM -0500, Kenneth Marshall wrote: > On Wed, Mar 17, 2010 at 04:53:37PM -0400, Ryan Suarez wrote: > > Does an entry in header_checks need to be defined for each > > recipient? If so, it wouldn't be feasible due to the number of > > addresses we have. Is there another way to accomplish this? > Can you use a pcre/regex map instead? Noel was talking about header_checks(5), which by definition must be a pcre_table(5) or a regexp_table(5). But as covered by other posts in the thread, it's a bad idea to do header-based routing. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Mail rejected on "Received From"
On Thu, Mar 18, 2010 at 06:43:29PM +, Kay wrote: > I often see mail being rejected by recipient servers because > an IP in a Received From header is blacklisted somewhere. > > This strikes me as a rather bad practise, since it undermines > the whole idea of SMTP authentication. > > Here's an example reject: > > 550 5.7.1 This system has been configured to reject your mail. > An IP address (xx.xx.xx.xx) found in the message's 'Received:' > headers is listed by the lookup site 'sbl-xbl.spamhaus.org.'. > > xx.xx.xx.xx is the client's IP, a regular dynamic IP on a > broadband connection. Which shouldn't have any relevance. I have mixed feelings about this. Yes, it is a misuse of a DNSBL, but if the IP is on SBL, indeed, the sender is probably a spammer, even in the unlikely event that the mail itself is not spam. I'd be fine with rejecting that. I don't do this, but I think it's reasonable. (I'd test it out before going live with it.) When it gets to XBL, things are less clear. If the sender is the person responsible for the spamming host, the sender does need to fix the problem. But many times the sender is an innocent bystander (bypasser) using a poorly-run public hotspot or hotel connection. I lived in an XBL-listed hotel[1] for two months once! No point in complaining to the manager (I actually did try!) because it's all contracted out to lousy companies. They can't do anything even if they can understand what you're saying (which is of course not likely; I failed to explain it to my hotel manager.) So there, I'd err on the side of caution. When it gets to PBL it is insanely, maddenly, stupid. > To make matters worse, the offending recipient site does not accept > mail for abuse/postmaster or any of the usual aliases. > > How do you engage hosts like these to resolve such issues? Noel's workaround is good. OTOH, sites that are stupid get what the postmaster deserves. It's too bad that there are so many poorly-run mail hosts. All we can do is commiserate and suggest you nominate these sites for rbl-ignorant.org. [1] I ran into that problem early on and fixed the issue myself by relaying my outbound mail through my VPN to my own mail host. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: master.cf override main.cf parameters exception list?
On Thu, Mar 18, 2010 at 06:12:32PM -0400, zhong ming wu wrote: > I find that not all parameters in main.cf can be overridden in > master.cf with -o. > > So far I find that for example header_check , smtpd_data_restrictions, > and inet_interfaces cannot be overridden in master.cf > Is there a list of such parameters documented somewhere? Correlation does not indicate causation. You have made an observation and drawn a false conclusion from it. > I am using three different postfix personalities defined in master.cf. "Personalities" is not a valid concept here, but I think my guess might point you in the right direction. > One for local processes listening at loopback > address. Another for public facing mx host listening on smtp port. > Another for authenticated clients using submission port > for relay > > I am currently trying to achieve the following: remove "Received:" > header from submission > port mails using header_checks=regexp/etc/postfix/map > > First I have no header_checks in main.cf and specify > header_checks=regexp/etc/postfix/map > only for submission server. This does not do anything to any of > three servers. You cannot set header_checks for a smtpd(8) daemon. But you can set $cleanup_service_name and use an alternate cleanup(8) daemon for an alternate smtpd. http://www.postfix.org/postconf.5.html#cleanup_service_name The -o options only override settings specific to the particular daemon you're trying to change. See the man page for each daemon. This page might help you understand the Big Picture: http://www.postfix.org/OVERVIEW.html You also mentioned trying to override smtpd_data_restrictions and inet_interfaces. The former, as hinted by the smtpd_* naming convention, is a setting for smtpd. The latter is a setting used by master(8), and as such, is global to the Postfix instance. There is, however, no need to override it for any daemon; you simply tell that daemon via its master(5) entry to bind to the appropriate IP address: 192.0.2.25:587 inet n - n - - smtpd -o setting=value [ ... ] This gives you a smtpd listener on 192.0.2.25:587. smtp unix - - n - - smtp -o smtp_bind_address=192.0.2.25 -o setting=value [ ... ] This gives you a smtp(8) client sending from 192.0.2.25. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: policy service for multiple recipients
On Fri, Mar 19, 2010 at 12:27:21PM +0200, Alex wrote: > Noel Jones wrote: > >On 3/18/2010 10:41 AM, Alex wrote: > >>In case of am multi-recipient message, if I use > >>check_recipient_access and one of recipients is found in that > >>table, the all message is rejected and affects all recipients > >>of the message. > > > >No, that's not how postfix works. Only the "current" recipient > >is rejected. Every other recipient gets their own chance to be > >accepted or rejected. snip > Thank you for you answer but I can't figure what is wrong. I > review my config and make more tests. The relevant part is that : > > 1. if I use telnet , connect to the server > > Mail From: > RCPT TO: > 250 2.1.5 Ok > RCPT TO: #listed recipient > 554 5.7.1 : Recipient address rejected: some text > DATA Different SMTP clients act differently. Here you are the client. You're remembering that you had a 250 for recipient1, so you did not abort at the 554 for recipient2. You went on through DATA, successfully completing the SMTP session. > 354 End data with . > test > . > 250 2.0.0 Ok: queued as A532D67CC4B > > The message is delivered to the first recipient (correct and > described behavior) And this is typical of MTA SMTP clients. > I have put the server in verbose mode and do the same test but > with thunderbird and a webmail client. snip > Both recipients are evaluated , the second gets rejected but no > message is delivered (to the first recipient) You cut out the relevant part of the logs, which in NON-verbose mode would have probably showed the client disconnecting. It ended the session without DATA. > Viktor also wrote : > "From false premises (the above is not true), you get false > conclusions. Postfix rejects just the recipient in question. If the > sending SMTP client fails to process the rejection of a single > recipient out of many correctly, then this client is the problem. > Generally, only MUAs and other "submission" SMTP talkers have such > issues. If you are an MSA for poorly" Thunderbird is a MUA, a submission client. It's not a MTA. It looks like it considers any rejection to be absolute. "Attachment issues," you might call it in psychobabble; it cannot handle rejection. Maybe it's a bug ... strictly speaking it is, but the role of a MUA is different, so perhaps this is the best thing for a MUA to do. It alerts the user that his/her recipient list has problems, and forces the user to correct those problems before sending the mail. As Victor was saying, this is not uncommon for submission clients. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Mails bounced 550 5.7.1
On Fri, Mar 19, 2010 at 03:06:42PM +0100, Sam Przyswa wrote: > On last Postfix install on new server some mails are refused with > error 550 5.7.1 se the report : > > > : host gw.aflo.be[87.66.26.108] said: 550 5.7.1 Your email >messages have been blocked by the recipient OR by Trend Micro Email >Reputation Service. Contact the recipient or his/her administrator using >alternate means to resolve the issue. (in reply to RCPT TO command) > This means that the recipient or the Trend Micro Email Reputation Service is blocking you, and you might be able to resolve the issue if you contact the recipient or his/her administrator using some other means, i.e., a freemail account or phone call. You could try postmas...@aflo.be, but I doubt that would get through. > How to fix ? See above. Apparently you are assuming that there is something wrong in your Postfix install. While this is possible, nothing you showed us here suggests that. I don't even know what basis you had for this assumption. Email deliverability issues are very difficult. While some discussion of these issues is tolerated on here, it's not on topic here. We cannot discuss YOUR issue because you didn't think you needed to provide any information with this post. My WAG: maybe you don't have good FCrDNS for your host. See: http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS Do note: - This is not a Trend Micro nor aflo.be support forum - There is no Trend Micro plugin for Postfix -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: alternatative to Mailman
On Fri, Mar 19, 2010 at 08:50:01AM -0300, Mauro Faccenda wrote: > I know this isn't exactly a Postfix question, but as postfix's I plan to make it one. :) > administrators the users of this list probably can answer the > question. > > Does anyone can recommend any good alternative to Mailman as a > Mailing Lists Manager that plugs well with Postfix? > > My only problem with Mailman is that I can't have two lists with > the same 'mailbox' (the part before the @) in different virtual > domains (i.e. supp...@company.com and supp...@anothercompany.com), > and this is mandatory in my setup. There are dozens of workarounds for this limitation. First, why does the list name itself matter? What matters is that actual email addresses are aliased to the list commands. Example virtual(5) mapping: supp...@example.com example.com_supp...@localhost supp...@example.net example.net_supp...@localhost supp...@example.org example.org_supp...@localhost And other mappings as needed for the various Mailman commands. In this example, the outside senders see and use the right support@ addresses, and only the help desk people see the real list names of "domain.tld_support". Second, this is trivially solved with multiple instances. You could have config_directory as subdirectories of /etc/postfix/ such as /etc/postfix/example.com, and do likewise for the queue_ and data_directory for each instance. http://www.postfix.org/MULTI_INSTANCE_README.html I don't know about other MLMs, but I am sure you can solve your problem with some Postfixation. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: master.cf override main.cf parameters exception list?
On Fri, Mar 19, 2010 at 08:03:47PM -0400, zhong ming wu wrote: > On Thu, Mar 18, 2010 at 7:16 PM, /dev/rob0 wrote: > > On Thu, Mar 18, 2010 at 06:12:32PM -0400, zhong ming wu wrote: > > > > "Personalities" is not a valid concept here, but I think my guess > > might point you in the right direction. > > This is the terminology used in master.cf manual page. Oops, in that case I will look again, thanks. > > You cannot set header_checks for a smtpd(8) daemon. But you can > > set $cleanup_service_name and use an alternate cleanup(8) daemon > > for an alternate smtpd. > > http://www.postfix.org/postconf.5.html#cleanup_service_name > > Great: this trick solves my problem. Thanks Glad to hear it, you're welcome. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Greylist server recommendations?
On Tue, Mar 23, 2010 at 10:55:04AM +0100, Bas Mevissen wrote: > On Tue, 2010-03-23 at 10:24 +0100, Ansgar Wiechers wrote: > > On 2010-03-22 Bas Mevissen wrote: > > > Why catch-all? Because I often use the part before the "@" > > > as a key to see the origin of the e-mail when subscribing. > > > > That's what address extension was invented for. See the > > respective section of man 8 local. > > I'm aware of address extension. I think maybe I have discussed this with you before as well. > It is a well-known trick, so the > extension is likely to be stripped off by spam senders. Funny thing about that. I have exactly one spamtrap address, and precisely because of spammers stripping the extension. Some years back, I made a few posts to a mailing list using this address: list+el...@nodns4.us . Note, no munging considered necessary. That address is not spammed at all; neither is the list@ address. el...@nodns4.us is my spamtrap! I get lots of hits on that, over 2000 in the past month. So, IME there is nothing to support your assumption about spammer behavior. I would know it if the list@ address started to get hit. I'd still be able to control it, because the only valid use of that address have been list sunscriptions, each containing a +tag. But this hasn't been necessary. Moral of the story: maybe harvest bots are dumber than you think. Likewise, perhaps, so is your catchall. :) To be fair, I have used user+t...@addresses in other situations, and in those cases it's not possible to say with certainty that user@ wasn't added to some spam list behind the scenes. But there too, I'm able to say that spam is not a major problem for me. HELO checks and Zen catch all but a few. Oh, this was about greylist server recommendations, so I'll toss in my opinion about that as well. I used to use sqlgrey. It is a fine piece of software, well and actively maintained (even when Lionel took a hiatus, he got a standin maintainer. The list, although very quiet, is monitored.) I stopped using it years ago. The pain of greylisting wasn't worth the minimal benefits. I did not notice any substantive, measurable difference in spam with and without greylisting. I think by now the vast number of spambots mean that it's feasible for any given zombie to go through its list more than once. I *do* think that much of what little zombie spew I see comes in twice. Possibly the occasional lack of the second copy means that the CBL picked it up in the meantime. Spamhaus PBL was extremely effective against zombies, as was the widespread blockage of outbound port 25. I think the battle against zombies will be shifting back to the relay-through-smarthost model rather than the direct-to-MX model. This means that a postmaster's job will be getting much harder. Imagine that! -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Directing SPAM mail to a Junk Folder
On Thu, Mar 25, 2010 at 05:05:47PM +0530, Chaminda Indrajith wrote: > I need to put the SPAM mails into users' Junk Mail folder. How > can we do it in Postfix? > > Mails are stored in Maildir format in the user's home directory. > Junk mail folder is inside the Maildir as ".Junk". Amavisd-new > tags the spam mails as "[SPAM]" Amavisd-new can also use a recipient_delimiter and change the localpart "user" to "user+spam". See amavisd-new documentation to learn how to activate this feature. Postfix local(8) can handle this differently by using a ~user/.forward+spam file. Postfix virtual(8) can handle this differently by using a different virtual_mailbox_maps result for user+s...@example.com . References: http://www.postfix.org/postconf.5.html#recipient_delimiter http://www.postfix.org/local.8.html http://www.postfix.org/aliases.5.html http://www.postfix.org/virtual.8.html http://www.postfix.org/postconf.5.html#virtual_mailbox_maps -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: how to allow a rejcted domain
On Thu, Mar 25, 2010 at 03:40:55PM +, Jamie Griffin wrote: > Mar 25 15:04:45 fix postfix/smtpd[11095]: NOQUEUE: reject: RCPT > from pih-inmx03.plus.net[212.159.10.4]: 450 4.1.8 > : Sender address > rejected: Domain not found; fhw-workplace02.servers.plus.net is the domain that does not exist. The REAL problem that needs to be addressed is that the sender is trying to use an invalid sender address. These deserve to be rejected. That said, recently I did a special order from Lowe's (a big USA retailer), and they outsourced their order service to some silly company which did not understand this VERY BASIC issue in email. (That company is called "IBM".) Since I needed the order, I had to whitelist, ugh. It was very painful, thinking of how much money Lowe's pays IBM for that fine service, and me being in need of a job. :) > So i tried letting this domain through by putting .plus.net into a > file: You need to understand the documentation of parent_domain_matches_subdomains. Unfortunately, I don't know enough to explain it to you. :) But I'm fairly sure in your case that the leading dot pattern was not looked up. I unset this: parent_domain_matches_subdomains = so, for me, something similar (with ihost.com) is what worked. > hash:/usr/pkg/etc/postfix/whitelist_sender > > like so: >/usr/pkg/etc/postfix/main.cf : >smtpd_sender_restrictions = > check_sender_access hash:/usr/pkg/etc/postfix/whitelist_sender, > [ ... ] > >/usr/pkg/etc/postfix/whitelist_sender: >.plus.net OK -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Directing SPAM mail to a Junk Folder
On Fri, Mar 26, 2010 at 08:26:33AM +1100, Voytek Eymont wrote: > so, if I was to create a mail user 'voytek+spam' in the database, > '+spam' mail would end up in voytek+spam mail user maildir ? The user for virtual(8) must be the full address: voy...@example.com example.com/voytek/maildir/ voytek+s...@example.com example.com/voytek/maildir/.spam/ ot...@example.com example.com/other/maildir/ other+s...@example.com example.com/other/maildir/.spam/ The concept of "user" is blurred here. To virtual, these are like different users. But to your IMAPd, ideally, you are simply delivering mail to another folder owned by that virtual user. There might be SQL tricks you can use to get the +spam queries to return the spam mailfolder paths, too. That's beyond the scope of this list, and beyond my very modest SQL literacy level. But DB storage is cheap, and it's easy to script something like this to populate your database for all existing users. > is that what I would need to as as 'next step' within above setup ? > > how to make that as a spam subfolder for 'voytek' ? > > is that something like... symlinking ?? voytek+spam mail user to > voytek's spam folder ?? > > sorry for dumb question, pls speak slowly... No problem, but at this point you should look at your IMAP server documentation on how to deliver to a virtual user's subfolder. The example above, I think, will work with Dovecot, but it assumes that voy...@example.com has $virtual_mailbox_base/example.com/voytek/ as HOME, and $HOME/maildir/ as top-level folder. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: how to allow a rejcted domain
On Thu, Mar 25, 2010 at 05:43:11PM +, Jamie Griffin wrote: > > You need to understand the documentation of > > parent_domain_matches_subdomains. Unfortunately, I don't know > > enough to explain it to you. :) But I'm fairly sure in your case > > that the leading dot pattern was not looked up. I unset this: > > parent_domain_matches_subdomains = > > so, for me, something similar (with ihost.com) is what worked. > > I had briefly looked at that setting earlier but thought just > using the .domain.tld notation would be ok. Just having another > read about that, it looks as though I need to set it like this: > > /usr/pkg/etc/postfix/main.cf: >[ ... ] >parent_domain_matches_subdomains = smtpd_access_maps >[ ... ] > >is that right? No. If you tell Postfix to match subdomains, the lookup that does this is the domain name WITHOUT the leading dot. For example, this: ihost.com permit_auth_destination would match for a check_sender_access lookup of i...@low1ap106.infra.secaucus.mebs.ihost.com . (Maybe my complaint went up the line, because I see that name now has an A record. Go figure!) If you unset parent_domain_matches_subdomains as I suggested, the lookup would be this, with the leading dot: .ihost.com permit_auth_destination If you have a parent_domain_matches_subdomains list which does NOT include smtpd_access_maps. I am not sure how that is handled. My guess is that the leading dot lookup is used. > I also understood that using the $smtpd_sender_restrictions > parameter would be the right way to whitelist this domain for what > i'm trying to achieve, have I got that right? You have what is IMO an unwieldy and hard-to-manage set of smtpd restrictions. Personally, I prefer keeping most or all restrictions in a single stage, smtpd_recipient_restrictions. However, IIRC from your OP, you did have the reject_unknown_sender_domain only in smtpd_sender_restrictions. Therefore yes, you are right. But to understand why, you should know that reject_unknown_sender_domain that caused your rejection. Anywhere you use that restriction, you must precede it with your whitelist lookup. Ugh. Do consider standing up for the principle of requiring senders to use real domains in their email addresses. I would have done so myself, but I knew they were not going to resend the bounced email. :) (IIRC it was just a copy of my invoice, which I had from my Web browser anyway.) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: sender_dependent_relayhost_maps + recipient_bcc_maps
On Thu, Mar 25, 2010 at 12:48:33PM -0400, Damon Miller wrote: > Hello. I've configured Postfix to relay mail from a specific > address to a remote MTA through 'sender_dependent_relayhost_maps' > and that works fine. I now want to BCC an address for messages > sent by this same user. The most obvious option seemed > 'recipient_bcc_maps', but unfortunately I'm not receiving the BCCs. Why is this obvious? recipient_bcc_maps :: BCC maps indexed by RECIPIENT address sender_bcc_maps :: BCC maps indexed by SENDER address Sounds to me like you might have wanted the latter. > # postconf -n I was going to skip the rest of this, but this caught my eye: > relay_domains = $mydestination,cloudswitch.com,hotmail.com This is very wrong, unless you are a MX host for cloudswitch.com and hotmail.com. You probably need to unset this. relay_domains = References: http://www.postfix.org/ADDRESS_CLASS_README.html#relay_domain_class http://www.postfix.org/postconf.html#relay_domains -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: how to allow a rejcted domain
On Fri, Mar 26, 2010 at 12:22:55AM +, Jamie Griffin wrote: > I'm going to re-read about smtpd_*_restrictions to better > understand what i've done because from what you've said I > could improve my configuration "Improve" is a value judgment. I think it's fair to say that management is easier if you stay within a single stage. But some restriction combinations need multiple stages. I didn't see anything in yours that couldn't be done in one stage, but then, I don't know what's in your access maps. > but can i ask quickly, do you mean I can move all of the smtpd > restrictions i'm using into $smtpd_recipeint_restrictions ? With the caveat that "recipient" must be spelled correctly, yes. :) Reference: http://www.postfix.org/SMTPD_ACCESS_README.html -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Directing SPAM mail to a Junk Folder
Please don't top-post replies. Also note, I set Reply-To: to keep discussions on list. I do not want a CC:. On Fri, Mar 26, 2010 at 06:03:47AM +0530, Chaminda Indrajith wrote: > ~user/.forward+spam would be a good solution for me since my > users are system users. > > Could you give me an example for the following? I can configure > amavisd-new to do + address extension. > > ## Deliver user+s...@example.com mails to /home/user/Maildir/.Junk > > .Junk is also in Maildir format. Sure. While I would prefer to see you try it yourself, this will complete the thread for the archives. I gave Voytek examples for virtual(8), so here's yours: u...@server:~$ echo '/home/user/Maildir/.Junk/' > ~/.forward+spam The file should be owned and readable by this user. Likewise, /home/user/Maildir/.Junk/ needs rwx permissions for this user. The trailing slash on the directory name is what tells local(8) that you're using a maildir. Most OS's that I have experience with have a /etc/skel directory which is used to populate the HOME for a new user. You can't use variables like $USER in a .forward file, and you obviously cannot have an absolute path in a skel file, but this worked for me: r...@server:~# echo '~/Maildir/.Junk/' > /etc/skel/.forward+spam Quoting is necessary there to prevent expansion of "~". Consult your OS documentation for information on new user creation and default files. > >References: > > http://www.postfix.org/postconf.5.html#recipient_delimiter > > http://www.postfix.org/local.8.html > > http://www.postfix.org/aliases.5.html -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Special rules for delivery to one address needed
On Mon, Mar 29, 2010 at 02:32:23PM +0200, Dirk Taggesell wrote: > there is an internally used development server with a fairly > default postfix installation. For testing software I want to > have postfix listen on an additional port and every mail > incoming on this port should not be delivered as usual but > instead being forwarded to a single address on the internal > mail server (different server). Mails incoming on port 25 > instead should be delivered normally. > > So I set up another rule in master.cf: > > localhost:485 inet n - - - - smtpd > > and postfix is now listen to port 485 as well. But now I'm > stuck. Where do I want to go from here? A transport rule? > Virtual? Always_bcc? What would be the best/canonical way to > achieve this? I would suggest a static: map for virtual_alias_maps, in a separate instance of Postfix. You might want a transport(5) for the single target address to the internal server in this instance. Note: when using static: for virtual_alias_maps, it is necessary to unset virtual_alias_domains. Google should be able to find one or more examples of this on this list. Multiple instance management is greatly improved in 2.6 et seq., so this might be a time to consider upgrading if you are not already using 2.7. http://www.postfix.org/MULTI_INSTANCE_README.html -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Logrotate with Postfix
On Mon, Mar 29, 2010 at 11:54:54AM -0400, James R. Marcus wrote:
> Does anyone have logrotate working correctly for maillog on a
> weekly basis? I'm not sure if its my logrotate config:
It is.
> /var/log/maillog {
> rotate 100
> compress
> weekly
> dateext
> notifempty
> copytruncate
> postrotate
>/etc/init.d/postfix reload
Why? This is the error. You need to restart your syslog daemon.
> endscript
> }
>
> Can someone who has this working correctly post their logrotate
> config.
This works out of the box with Slackware, and probably any other OS
which ships logrotate. My config would not be useful to you. You
should be looking in your OS documentation and follow up to a forum
for your OS.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Re: problems with permit_sasl and unknown_address
On Sun, Apr 04, 2010 at 07:03:56PM -0600, Yves Dorfsman wrote: > smtpd_helo_restrictions = reject_non_fqdn_hostname, > reject_invalid_hostname > > I will comment them out and see if it works. I suspect they > don't do a lot in terms of fighting spam anyway. This guess would be very wrong. reject_non_fqdn_helo_hostname (you are using deprecated syntax) is the single best low-cost antispam weapon in the arsenal. When I have checked, it seems to block around 25% of all connections, and no known problems from using it. Of course, I use it right. If I was going to have client submission on the same port, I would precede it with the appropriate permit_* restrictions as needed. You might also benefit from consolidation of your restrictions into smtpd_recipient_restrictions. It's easier to understand what's going on that way. Reference: http://www.postfix.org/SMTPD_ACCESS_README.html -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: pop-before-smtp why I use.
On Tue, Apr 06, 2010 at 08:11:02AM -0600, Josh Cason wrote: > When I built the server after doing tons of research. (the old > servers ran sendmail and I didn't have a hand in setting them up.) > pop-before-smtp worked great for customers outside the network. At best, pop-before-smtp is an ugly kludge. It is not truly implemented as a feature of any MUA I know; the user simply has to remember to check mail before hitting "send". > If I disabled pop-before-smtp they would not work. Just internal > users. So without any changes to the outside world in there > e-mail clients. As long as they had a proper username / password > it worked great. Sometimes there is no way to avoid making changes in the outside world. Your site sounds way overdue for SASL AUTH. > My e-mail server worked great for 1 year before (I assume > this new type of spam) starting showing up in my server. What "new type of spam" is this? I think there is no such thing. You need to show NON-VERBOSE logs of this "new spam" coming in. Others have told you that. You are not complying. Why not? > Now for about 1 year I have been adding and trying different > configurations to get ride of it. Seems to be a partial open > relay. A whole YEAR of relaying spam? That is shameful. You mention the "open relay" phrase, and that brings to mind one possible WAG I can share with you. Perhaps a year ago you changed your router upstream from your Postfix. If the router is doing destination NAT inbound to the Postfix, it MUST *NOT* also do source NAT on those connections. Example: Router external IP: 192.0.2.25 Router internal IP: 192.168.2.254 Postfix (internal-only) IP: 192.168.2.25 1. Router receives connection to 192.0.2.25:25 (inbound mail/spam) 2. Router changes (masquerades) the source IP to 192.168.2.254 3. Router passes NAT'ed connection through to 192.168.2.25:25 4. Postfix at 192.168.2.25 sees the connection as coming from the Router, 192.168.2.254 This is one of very few ways that Postfix can unintentionally become an open relay, and note, the problem and solution is external to Postfix. If this guess is right, you CANNOT use pop-before-smtp unless the router is fixed or replaced by something sane. Whenever ANY user authenticates with POP3, from anywhere, you are an open relay until whatever timeout you have set for the pop-before-smtp. It is very much like playing Russian roulette with email. Unsafe. > I don't know what it is caused by and I'm trying my best to spot > or give all you helpfull people information needed to sqash this. > I can't thank you enough once again for help. You need to show NON-VERBOSE logs of this spam coming in. Nothing beyond wild guesses will be possible until you heed that. > In this area I'm alone and don't have any help. Most people > suguested paying a service to host e-mail and I'm like that is > stupid. But now with my spare time involved in this. I question > that. Indeed. Mail administration is very challenging, and to be quite frank, you are not showing any aptitude for the job. I think the suggestion is a very good one. Not everyone can be a postmaster. Those who succeed worked at it, very hard. Google Apps will do email hosting for free. (No, they probably will not support pop-before-smtp, nor should they.) > But I have two problems with spam and this is a pretty big > problem. If I could squash it. Then my e-mail server would be > close to perfect. Not perfect because I was the only one knowning > linux and setup other linux projects that work great. Like routers, > and what not. Just not so good at e-mail. If my guess was right, you're not so good at routers, either. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Am I really using a CIDR map?
On Tue, Apr 06, 2010 at 11:57:00AM -0600, Robert Lopez wrote: > On Tue, Apr 6, 2010 at 10:52 AM, Noel Jones > wrote: > > On 4/6/2010 11:39 AM, Robert Lopez wrote: > >> Why does postfix not like the source file being removed from the > >> /etc/postfix directory? > > > > cidr tables are plain-text tables. The source file is the live > > table data. The .db file is your mistake; cidr tables should not > > be indexed with postmap. > > That surprises me. > > The man page seems to me to indicate otherwise. > My confusion is with this sentence: > "These tables are usually in dbm or db format." > which is from the Description portion below... Yes, and it continues: "Alternatively, lookup tables can be specified in CIDR ... form." Taken together, with emphasis added: "These tables are USUALLY in dbm or db format. ALTERNATIVELY, lookup tables CAN BE ..." Perhaps the wording can be improved. The "usually" part is not so relevant as are the particulars of what a cidr: map should be. " The Postfix mail system uses optional lookup tables as described in the DATABASE_README document. Lists of IP addresses can be specified in CIDR (Classless Inter-Domain Routing) form. In this case, a plain text file is the map, with the standard "key whitespace value" format. When a match is found, the corresponding result is returned and the search is terminated. " I know, it's probably not appropriate to refer to a README in that part of a man page, but it seems more thorough and less likely to confuse, to me, than the "usually" verbiage. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
