Wildcard for domain instead of user?
I don't know if this is possible in a virtual alias (or even virtual) set up, but I would like to be able to set up a user name with a wildcard domain. Here's what I mean: I host several domains. I would like the address '[EMAIL PROTECTED] ' to go to the same place (me). So my initial thought was to set up in my virtual alias table an entry like this: [EMAIL PROTECTED] [EMAIL PROTECTED] I use MySQL lookup tables. Will this work? is there a different way to specify the wildcard? is there a different approach I should take to making this work? Any help is much appreciated! -- Jeff Weinberger http://disruptivemarketing.jeffweinberger.com
Content filtering using MySQL table
Hi: I"m using content filtering by using the following (this is the example) syntax in master.cf: smtp inet ...other stuff here, do not change... smtpd -o content_filter=myfilter:myfilter myfilter unix - n n - 10 pipe flags.. All is working as expected. According to the directive documentation, the content_filter directive I am using above can take a transport(5) table (hash:, pcre:, etc.) to use different transports for different domains Does anyone know if I can use a MySQL lookup for this? with a syntax like: smtp inet ...other stuff here, do not change... smtpd -o content_filter=mysql:/etc/postfix/mysql_filter_maps.cf with mysql_filter_maps.cf using a syntax like: user = postfix_sql_user password = postfix_sql_password hosts = localhost dbname = postfix_sql_database_name query = SELECT filter_result FROM filter_table WHERE domain='%s' The reason I'd do this is to be able to add a domain or change content filtering for a domain on the fly without having to reload postfix Also - what happens if I don't want content filtering for a domain, and I just don't have that domain in the lookup table? (i.e. the query returns a NULL result or no rows found result? The desired outcome is that no content filtering is performed, Any help or advice is much appreciated! Thank you!
Implementing autoreply for all received mail (including internally forwarded)
Hi: I am hoping I can ask for suggestions or pointers to help solve this challenge. I am trying to implement an autoreply capability. I am putting together a script that will handle the messages. Many of the autoreply examples I've found suggest implementing this by: main.cf: always_bcc = autoreply local_alias_maps: autoreply '|/path/to/autoreply/script' effectively causing all mail sent to anyone to be bcc'ed to the script, which then determines if an autoreply needs to be sent. This also ensures that delivery to the intended recipient (in my case, they are all virtual mailboxes) will also happen. However, as I started to test this, I discovered a limitation that I am having difficulty finding a solution for. The scenario is that one user on one domain that I host sends mail to another user at another domain that I host. The recipient has autoreply "turned on" in my script. However, according to http://www.postfix.com/ADDRESS_REWRITING_README.html : "To avoid mailer loops, automatic BCC recipients are not generated for mail that Postfix forwards internally" and the actual behavior matches that statement. So my question: Is there another mechanism I can use to send the mail to the script without interfering with normal mail delivery in all cases , including this internally forwarded mail? Or, is there another way to handle autoreplies that anyone can suggest or point me to that avoids this issue? (I don't want all mail forwarded to the script, as I do not want to - and am not sufficiently proficient to - handle reinjection into postfix and the associated handling of SMTP/LMTP protocol) Thank you very much for any help or pointers you can offer!
Can recipient_bcc_maps be over-riden in master.cf?
Hi: I am having a problem with duplicate bcc's (from recipient_bcc_maps) and I suspect I know why - but I hope someone can point me to a solution. I have a content filter set up for dspam (content_filter = dspam:dspam in main.cf) set up as described in the "Advanced content filter example" section of http://www.postfix.com/FILTER_README.html - it works fine. Now I've added the ability for selected virtual mailbox addresses to trigger recipient_bcc_maps so that a bcc is generated to a specific address only when mail is sent to designated recipients. This is where the problem arises. When mail arrives, the bcc is generated and sent. Then when the mail is injected back into postfix after the content filter, another bcc is generated and sent. The secind bcc is, of course, undesireable. I tried adding: -o recipient_bcc_maps= to the overrides for localhost:10026 (where dspam reinjects the mail) but that did not change the behavior. It still generated the second bcc. I don't see this documented per se (am I missing something?), but can recipient_bcc_maps be over-riden this way? If not, is there another way to avoid the second bcc? Thank you for any help, pointers and/or advice you can offer!!
Finding the envelope-sender after always_bcc?
Hi: After reading http://www.irbs.net/internet/postfix/0703/1471.html and http://www.irbs.net/internet/postfix/0703/1519.html to help with my autoreply capability (and making sure i get it as close to "right" as possible!), I am trying to ensure that I can take all reasonable measures to get the autoreplies right (when they are sent). to this end, it's important that I capture the envelope-sender of each message in addition to the "From:" header, but I am having difficulty doing so. I have tried to send the message to my autoreply script via bcc: (via always_bcc or recipient_bcc_maps) to a local autoreply address which then has the transport autoreply: which calls the autoreply script via pipe or is a local alias that resolves to '|/path/to/autoreply/ script'. The transport mechanism has the ability to pass information from postfix, but doesn't seem to capture the envelope-sender correctly. I have tried using every single one of the macros listed in http://www.postfix.com/pipe.8.html to no avail. I have even used some macros that are not listed, but I've found in other examples as I've searched for solutions. This happens with mail sent to alias addresses as well as virtual mailboxes. Some e-mails from lists to which I subscribe include a "Sender: " header which looks like it contains the envelope-sender. Mail that shows up in my standard ISP account (not ever touching my postfix installation) seems to include the "Return-Path: " header which includes the envelope-sender. Leading me to two questions: 1) on-topic: How can I be sure I can find the envelope-sender for every message and pass that to my script? Or maybe I should ask it this way: How do I get postfix to keep the correct envelope-sender? 2) broader: Is the list of macros that can be used as arguments to a pipe command (as listed in http://www.postfix.com/pipe.8.html) complete? or are there others (like the ones I've found)? and where can I find a complete list? I would appreciate any help, direction or pointers that anyone can offer. It might help to know that messages entering my postfix server are then passed to a content_filter (Dspam, specifically, using content_filter=dspam:dspam), which then re-injects them back into postfix which then handles them and sends them to a delivery agent (mostly maildrop, sometimes virtual). If the order of this (and the passing through dpsam is affecting the envelope-sender, is there way to either get the message to the autoreply script before it goes to dspam (I don't want that, since I don't autoreply to spam messages) or a way to pass the envelope-sender through dpsam, or something else I haven't considered? Thank you!! and happy new year!!
Re: Finding the envelope-sender after always_bcc?
On Dec 31, 2008, at 6:11 PM, mouss wrote: Jeff Weinberger a écrit : Hi: After reading http://www.irbs.net/internet/postfix/0703/1471.html and http://www.irbs.net/internet/postfix/0703/1519.html to help with my autoreply capability (and making sure i get it as close to "right" as possible!), I am trying to ensure that I can take all reasonable measures to get the autoreplies right (when they are sent). to this end, it's important that I capture the envelope-sender of each message in addition to the "From:" header, but I am having difficulty doing so. yes, don't reply to From: addresses. if you can't get the envelope sender, don't autoreply. I have tried to send the message to my autoreply script via bcc: (via always_bcc or recipient_bcc_maps) to a local autoreply address which then has the transport autoreply: which calls the autoreply script via pipe or is a local alias that resolves to '|/path/to/autoreply/ script'. The transport mechanism has the ability to pass information from postfix, but doesn't seem to capture the envelope-sender correctly. The envelope sender should be found in the Retrun-Path header. when using a pipe, make sure to put the 'R' flag in the "flags=..." options. you can also use -f ${sender} in your pipe and have your scrpit parse command line args. I have tried using every single one of the macros listed in http://www.postfix.com/pipe.8.html to no avail. I have even used some macros that are not listed, but I've found in other examples as I've searched for solutions. This happens with mail sent to alias addresses as well as virtual mailboxes. Some e-mails from lists to which I subscribe include a "Sender: " header which looks like it contains the envelope-sender. Mail that shows up in my standard ISP account (not ever touching my postfix installation) seems to include the "Return-Path: " header which includes the envelope-sender. Leading me to two questions: 1) on-topic: How can I be sure I can find the envelope-sender for every message and pass that to my script? Or maybe I should ask it this way: How do I get postfix to keep the correct envelope-sender? always_bcc does not change the envelope sender (it changes the envelope recipient). so you get the "correct" envelope sender. 2) broader: Is the list of macros that can be used as arguments to a pipe command (as listed in http://www.postfix.com/pipe.8.html) complete? or are there others (like the ones I've found)? and where can I find a complete list? I would appreciate any help, direction or pointers that anyone can offer. It might help to know that messages entering my postfix server are then passed to a content_filter (Dspam, specifically, using content_filter=dspam:dspam), which then re-injects them back into postfix which then handles them and sends them to a delivery agent (mostly maildrop, sometimes virtual). If the order of this (and the passing through dpsam is affecting the envelope-sender, is there way to either get the message to the autoreply script before it goes to dspam (I don't want that, since I don't autoreply to spam messages) or a way to pass the envelope-sender through dpsam, or something else I haven't considered? check your logs to see if the envelope sender is present at delivery time. if your content filters and other stuff reinjects mail using the sendmail command, make sure to use -f to passe the (original) envelope-sender. Thank you! I've verified that the "R" flag is there and I use -f ${sender} on the command line (the script does parse the arguments) I think the envelope-sender is missing before it enters the content filter. This from my mail.log: Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=, size=1505, nrcpt=1 (queue active) Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from smtp120.isp.mail.sp1.myisp.tld[69.147.64.93] Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY - NOT AN ERROR): see sql.errors for more details Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[127.0.0.1] Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79: client=localhost[127.0.0.1] Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79: message-id=> Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>, size=2936, nrcpt=1 (queue active) Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from localhost[127.0.0.1] Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74: to=>, relay=dspam, delay=5.1, delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam service) (identifying information removed) The "from=<>" in the third-to-last line I assume should be the envelope-sender? This happens whether I send from my ISP mail address, another locally- hosted virtual mailbox or anywhere else. Is this part of the problem? If so, where can I start to look for a solution? or what information would be helpful? Thank you!
Re: Finding the envelope-sender after always_bcc?
mouss wrote: Jeff Weinberger a écrit : > > I've verified that the "R" flag is there and I use -f ${sender} on the > command line (the script does parse the arguments) > > I think the envelope-sender is missing before it enters the content > filter. This from my mail.log: > > Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=>, > size=1505, nrcpt=1 (queue active) > Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from > smtp120.isp.mail.sp1.myisp.tld[69.147.64.93] > Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY - > NOT AN ERROR): see sql.errors for more details > Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[1270.0.1] > Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79: > client=localhost[127.0.0.1] > Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79: > message-id= > Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>, size=2936, > nrcpt=1 (queue active) > Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from localhost[127.0.0.1] > Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74: > to=, relay=dspam, delay=5.1, > delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam service) > > (identifying information removed) > > The "from=<>" in the third-to-last line I assume should be the > envelope-sender? > yes. when mail is passed back to postfix, something loses the envelope-sender. how do you pass mail from dspam to postfix? From this log entry it looks like the envelope sender is empty before the mail is send to dspam - the "from=<>" three lines before the mail is delivered to dspam makes me think this. When I look at the log entries for the message when it comes back into postfix from dspam the envelope sender is also empty (again "from=<>" So isn't there something losing the envelope sender before it ever gets to dspam? but to answer your question directly, dspam re-injects the mail into postfix using SMTP on an alternate port, the same way as is illustrated in the CONTENT_FILTER_README for an after-queue content filter. Does that help? or point to anything?
Re: Finding the envelope-sender after always_bcc?
On Jan 1, 2009, at 9:31 AM, mouss wrote: jeff_homeip a écrit : --- In post...@yahoogroups.com, mouss wrote: Jeff Weinberger a écrit : I've verified that the "R" flag is there and I use -f ${sender} on the command line (the script does parse the arguments) I think the envelope-sender is missing before it enters the content filter. This from my mail.log: Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=, size=1505, nrcpt=1 (queue active) look at the queue-id: A4C5E2943D74 Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from smtp120.isp.mail.sp1.myisp.tld[69.147.64.93] postfix disconnects from 69.147.64.93. Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY - NOT AN ERROR): see sql.errors for more details dspam barks. so dspam got the message. Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[127.0.0.1] dspam connects to postfix (after the filter smtpd). Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79: client=localhost[127.0.0.1] this dspam connection has a queue-id of 646A62943D79 Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79: message-id= Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>, size=2936, nrcpt=1 (queue active) the envelope sender is empty for queue-id 646A62943D79, which corresponds to dspam re-injection. so dspam has reinjected the message with an empty sender. Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from localhost[127.0.0.1] Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74: to=, relay=dspam, delay=5.1, delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam service) once dspam has delivered the message, postfix tells you that the original transaction was delivered. this comes late because dspam does not queue mail, so postfix can't know that delivery _will_ succeed. [snip] From this log entry it looks like the envelope sender is empty before the mail is send to dspam - the "from=<>" three lines before the mail is delivered to dspam makes me think this. don't rely on the order of log lines. Instead, look at the queue-id: A4C5E2943D74 is the queue-id when postfix received the message from the network. 646A62943D79 is the queue-id when postfix received the message from localhost, which should be dspam re-injection. When I look at the log entries for the message when it comes back into postfix from dspam the envelope sender is also empty (again "from=<>" see above. the log doesn't tell you "I am about to pass mail to dspam". it tells you "mail was delivered, and it was done via dspam". This means that dspam took the message and said "OK" to postfix, and since dspam doesn't have a queue manager, this means that the message was already filtered and passed to postfix/smtpd (the "after the filter" one). So isn't there something losing the envelope sender before it ever gets to dspam? but to answer your question directly, dspam re-injects the mail into postfix using SMTP on an alternate port, the same way as is illustrated in the CONTENT_FILTER_README for an after-queue content filter. so the problem is in dspam. Does that help? I asked just to make sure it was not passing the message to something else that does the re-injection. Thank you! That helps clarify what I was missing in this - so clearly dspam is not passing the envelope sender back to postfix. I suspect it doesn't know how via SMTP, but it can also use the sendmail command to do this. I will experiment with this. would the correct command be "/usr/sbin/sendmail -f" ? thanks!
Re: Finding the envelope-sender after always_bcc?
On Jan 1, 2009, at 9:49 AM, mouss wrote: Jeff Weinberger a écrit : Thank you! That helps clarify what I was missing in this - so clearly dspam is not passing the envelope sender back to postfix. I suspect it doesn't know how via SMTP, but it can also use the sendmail command to do this. I will experiment with this. no, keep using smtp. just check your setup (and see why dspam barks about sql errors). ask on the dspam list. If you wnat to keep using dspam, you should follow the (recent) fork: http://www.dspam-community.org would the correct command be "/usr/sbin/sendmail -f" ? yes, but smtp is better. Thank you! I will ask on the dspam list about this. I've been reading the dspam docs this morning and the project owner states fairly strongly that sendmail is far preferable to SMTP re- injection (in the postfix setup docs), but doesn't say why. I don't know enough about the workings of dspam (yet) to know, but I'd tend to agree with you on the use of SMTP as more desirable. dspam has always had this mysql issue, which is related to its database of spam tokens, and I'll look into whether it might be related. Thank you for your help!
issue connecting to mysql after upgrade
Hello again: One more issue on which I would appreciate any help anyone can offer: Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and my MySQL installation from 5.0.51b to 5.0.75. Immediately after restarting everything (the whole computer), I started seeing these messages in my mail log: Jan 1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:35 s postfix/cleanup[13201]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:42 s postfix/trivial-rewrite[13205]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) As far as I can tell this has been consistent with smtpd, cleanup and trivial-rewrite, but nothing else. (there have been pre-existing issues, per my prior conversation with mouss, with dspam, but these have not changed at all - they existed before the upgrade and still exist) I use mysql for nearly all my tables in postfix. All of my aliases are working and forwarding fine, which means that postfix can access my mysql database (and yes, postconf -m shows mysql). virtual is finding the maildirs correctly for my virtual mailboxes. However, my sender_canonical_maps are no longer working after the upgrade (outbound addresses are not being rewritten at all as they were before the upgrade) As an example, my main.cf contains: sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf and mysql_canonical_maps.cf contains: user = postfixuser password = postfixpassword hosts = localhost, 127.0.0.1 dbname = postfixdatabase query = SELECT result FROM canonical WHERE address='%s' AND active='Y' (obvious information changed). This is unchanged before and after the upgrade. The query works on all the addresses (I tested it at the mysql command prompt). I also tested a local telnet to 127.0.0.1 on port 3306 which worked as expected and mysql responds perfectly. I also tested connection through the localhost socket with works as expected. Also several other parts of my mail system (e.g. courier_auth) connect through the socket and report success. And as noted, postfix is able to connect most of the time (aliases, virtual maildirs, etc.). Other software on my system, e.g. PHP, is also able to connect to mysql successfully. I tried all the steps in the MySQL documentation on dev.mysql.com suggested to diagnose this error, and all confirmed that the MySQL server is working correctly. So I find myself not knowing where to look next, and I hope someone here knows what might be happening or at least be able to point me in the right direction. One additional piece of information: I am running on Mac OS/X and as part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus needing to restart my computer). This upgrade is known to break postfix. So I reinstalled postfix and my main.cf and master.cf files after the upgrade and stopped and restarted postfix to be sure. (and mysql) What other information might be helpful in diagnosing this? Thank you for any help you can offer!
Re: issue connecting to mysql after upgrade
On Jan 1, 2009, at 1:55 PM, mouss wrote: Jeff Weinberger a écrit : Hello again: One more issue on which I would appreciate any help anyone can offer: Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and my MySQL installation from 5.0.51b to 5.0.75. Immediately after restarting everything (the whole computer), I started seeing these messages in my mail log: Jan 1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:35 s postfix/cleanup[13201]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:42 s postfix/trivial-rewrite[13205]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) As far as I can tell this has been consistent with smtpd, cleanup and trivial-rewrite, but nothing else. (there have been pre-existing issues, per my prior conversation with mouss, with dspam, but these have not changed at all - they existed before the upgrade and still exist) I use mysql for nearly all my tables in postfix. All of my aliases are working and forwarding fine, which means that postfix can access my mysql database (and yes, postconf -m shows mysql). virtual is finding the maildirs correctly for my virtual mailboxes. However, my sender_canonical_maps are no longer working after the upgrade (outbound addresses are not being rewritten at all as they were before the upgrade) As an example, my main.cf contains: sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf and mysql_canonical_maps.cf contains: user = postfixuser password = postfixpassword hosts = localhost, 127.0.0.1 dbname = postfixdatabase query = SELECT result FROM canonical WHERE address='%s' AND active='Y' (obvious information changed). This is unchanged before and after the upgrade. The query works on all the addresses (I tested it at the mysql command prompt). I also tested a local telnet to 127.0.0.1 on port 3306 which worked as expected and mysql responds perfectly. I also tested connection through the localhost socket with works as expected. Also several other parts of my mail system (e.g. courier_auth) connect through the socket and report success. And as noted, postfix is able to connect most of the time (aliases, virtual maildirs, etc.). Other software on my system, e.g. PHP, is also able to connect to mysql successfully. I tried all the steps in the MySQL documentation on dev.mysql.com suggested to diagnose this error, and all confirmed that the MySQL server is working correctly. So I find myself not knowing where to look next, and I hope someone here knows what might be happening or at least be able to point me in the right direction. One additional piece of information: I am running on Mac OS/X and as part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus needing to restart my computer). This upgrade is known to break postfix. So I reinstalled postfix and my main.cf and master.cf files after the upgrade and stopped and restarted postfix to be sure. (and mysql) What other information might be helpful in diagnosing this? - check whether any services are chrooted in master.cf (the 5th field must be set to 'n' and not to 'y' or '-')? All chroot flags are set to "n" - try using proxymap (foo_maps=proxy:mysql:/etc/). Tried this...no change :( - make sure the mysql socket is accessible by postfix (and not just by root). I checked looking at permissions and trying it as the postfix user and all works (I suspected it would, as many accesses work fine (aliases, etc. as I noted earlier) - try with "hosts = 127.0.0.1" (without "localhost") Tried this - no change. :( I tried each of the suggestions you made with alias, virtual and local addresses I noticed that when local complained about mysql access, it still did fine looking up the local alias and forwarding it correctly. I'm starting to wonder whether this is a "can't connect" or a delay in connecting - is it possible that it's taking too long to connect so a warning is reported, but the connection happens eventually? or that it works on a retry? The only thing I've found that doesn't work as expected is sender_canonical_maps which would invalidate this theory, but the local behavior makes me think it's a possibility? Alternatively, is it possible that something in the mysql capabilities of postfix compiled wrong? I am not that familiar with gcc and the build process (I use what I know works) - is there something I can look at in the ./configure or make output that would tell me? I did try rebuilding (./configure,. make, make in
Re: issue connecting to mysql after upgrade
On Jan 1, 2009, at 4:53 PM, mouss wrote: Jeff Weinberger a écrit : [snip] - try with "hosts = 127.0.0.1" (without "localhost") Tried this - no change. :( ahem. if you do this, you should not hear about a socket. it should use a TCP connection. can you show the errors? I would think so also. I'm at a loss here, but I think this is no longer a problem. i was able to turn on very verbose logging in mysql, and it turns out that all the queries are in fact being made. I also have to confess to a bit of stupidity about my own ability to hold enough configuration information in my head (making postfix much smarter than I am!). I have dspam set to filter all mail both inbound and outbound (this has to change, but served the purpose when I initially set it up. And to stop multiply always_bcc results, specified "-o receive_override_options=no_address_mappings" in the master.cf entry for re-injection. the pipe to dspam is case-folding and then the sender_canonical_maps are being ignored. I didn't event think to look at this as a reason canonical was failing. I apologize sincerely for taking so much time and effort to get here and for leading you down this path. But still I appreciate the help. This will help me clean up this set of configuration issues. As to the warnings, I still don't know. Everything seems to be working, but issuing warnings. Here are a bunch of the errors - from more reading I think the key is in the (38) which I think(??) is a postfix error code...is it? do you know what it means?: Jan 1 17:00:33 s postfix/smtpd[21502]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:00:33 s postfix/cleanup[21517]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:06:33 s postfix/trivial-rewrite[21546]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:06:34 s postfix/smtpd[21544]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:06:34 s postfix/cleanup[21547]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:42 s postfix/trivial-rewrite[21582]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:09:42 s postfix/smtpd[21581]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:42 s postfix/cleanup[21583]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:45 s postfix/local[21587]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:58 s postfix/trivial-rewrite[21592]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:11:50 s postfix/trivial-rewrite[21624]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:11:50 s postfix/smtpd[21623]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:11:50 s postfix/cleanup[21625]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:15:46 s postfix/trivial-rewrite[21648]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:15:49 s postfix/smtpd[21646]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:15:49 s postfix/cleanup[21649]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:19:10 s postfix/trivial-rewrite[21675]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) [snip] why do use sender_canonical instead of canonical? rewrite should be consistent, and "your sender is the recipient's recipient"... This is mostly because I use maildrop as the virtual delivery agent for many of the virtual mailboxes. I'm really just testing this, and may end up using canonical instead. But here's my thinking: I have one user who wants a minor change - sounds silly, but gives me a good chance to experimen
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 1, 2009, at 12:58 PM, mouss wrote: Jeff Weinberger a écrit : I've been reading the dspam docs this morning and the project owner states fairly strongly that sendmail is far preferable to SMTP re-injection (in the postfix setup docs), but doesn't say why. if he doesn't say why, then we don't know whether there was a problem at the time or if there is another reason. People have been using smtp mode without problems. I don't know enough about the workings of dspam (yet) to know, but I'd tend to agree with you on the use of SMTP as more desirable. dspam has always had this mysql issue, which is related to its database of spam tokens, and I'll look into whether it might be related. I don't think it is related, but check it though... First let me thank mouss for all his generous help on this - as it turned out, I was able to solve it with the information in this thread and http://www.pubbs.net/postfix/200811/3719/ from Victor but it required some trickery to get the envelope-sender past dspam. I'm posting my solution here in the hope that it might help someone else. I used a pcre: table for smtpd_sender_restrictions and the PREPEND action as follows: main.cf: smtpd_sender_restrictions = check_sender_access pcre:/etc/ postfix/smtpd_sender_restrictions.pcre smtpd_sender_restrictions.pcre /^(.*)/ PREPEND X-Envelope-Sender: ${1} this will insert into every message a header "X-Envelope-Sender: " followed by the envelope sender value. It won't pass the envelope- sender as SMTP MAIL FROM (dspam wasn't designed to do that, and until I take the step to a better before-queue filter or something that does, this will work, since all I needed was to capture the envelope- sender). Limited testing shows this to work. There might be cases beyond what I tested that will behave differently than I expect or very oddly. Thanks again!
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 2:30 AM, mouss wrote: Jeff Weinberger a écrit : I used a pcre: table for smtpd_sender_restrictions and the PREPEND action as follows: main.cf: smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/smtpd_sender_restrictions.pcre smtpd_sender_restrictions.pcre /^(.*)/ PREPEND X-Envelope-Sender: ${1} this will insert into every message a header "X-Envelope-Sender: " followed by the envelope sender value. It won't pass the envelope-sender as SMTP MAIL FROM (dspam wasn't designed to do that, dspam gets it via LMTP MAIL FROM, and it will pass it back to postfix with SMT MAIL FROM. I have used this in the past and I'm sure others are using it now (ping steve?). something in your setup prevents this from working but I don' think it is a dspam limitation. It's definitely my set up. I don't use LMTP to pass the message to dspam, I use a transport called "dspam" that uses pipe. That means there's no S/LMTP dialog, just the message itself passed as STDIN. I have to move dspam to use LMTP and then move it to a before-queue content filter so that this workaround becomes unnecessary, but until I go to make those changes, this will suffice. I'm not completely convinced that dspam will work seamlessly as a before-queue content filter, so I'll have to do some testing to see how well that works and whether it can do what I need and hand fully formed messages with SMTP dialog information back to postfix. Thank you!! and until I take the step to a better before-queue filter or something that does, this will work, since all I needed was to capture the envelope-sender). Limited testing shows this to work. There might be cases beyond what I tested that will behave differently than I expect or very oddly. Thanks again!
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 9:20 AM, mouss wrote: Jeff Weinberger a écrit : It's definitely my set up. I don't use LMTP to pass the message to dspam, I use a transport called "dspam" that uses pipe. That means there's no S/LMTP dialog, just the message itself passed as STDIN. so _you_ are not passing the envelope sender to dspam. Consider running dspam in "relay mode": postfix --(LMTP)--> dspam --(SMTP)--> postfix I have to move dspam to use LMTP and then move it to a before-queue why do you want to run it in pre-queue mode? This is not needed and is not simple to setup. If I understand your diagram, then the content_filter would look like: content_filter=lmtp:unix:/path/to/dspam args and that might pass through the envelope information (I'm not convinced, but if dspam can do it, that would be how). But since dspam can speak LMTP and SMTP why would an smtpd proxy be hard to set up? It would certainly avoid the bcc issues, etc. that I" experiences by having the message run through postfix twice. After reading through SMTPD_PROXY_README, it seems like a bit of a challenge to make it work, but not that hard...what do you think might be difficult? Thanks for all your help - over the course of thi dialog I've learned a lot about postfix and have become more aware of and proficient with parts I knew little about. This has been very helpful. content filter so that this workaround becomes unnecessary, but until I go to make those changes, this will suffice. I'm not completely convinced that dspam will work seamlessly as a before-queue content filter, so I'll have to do some testing to see how well that works and whether it can do what I need and hand fully formed messages with SMTP dialog information back to postfix.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
Wietse Venema wrote: Jeff Weinberger: [ Charset ISO-8859-1 unsupported, converting... ] > On Jan 2, 2009, at 2:30 AM, mouss wrote: > > > Jeff Weinberger a ?crit : > >> > >> I used a pcre: table for smtpd_sender_restrictions and the PREPEND > >> action as follows: > >> > >> main.cf: > >> smtpd_sender_restrictions = check_sender_access > >> pcre:/etc/postfix/smtpd_sender_restrictions.pcre > >> > >> smtpd_sender_restrictions.pcre > >> /^(.*)/ PREPEND X-Envelope-Sender: ${1} > >> > >> this will insert into every message a header "X-Envelope- Sender: " > >> followed by the envelope sender value. It won't pass the > >> envelope-sender as SMTP MAIL FROM (dspam wasn't designed to do that, > > > > dspam gets it via LMTP MAIL FROM, and it will pass it back to postfix > > with SMT MAIL FROM. I have used this in the past and I'm sure others > > are > > using it now (ping steve?). something in your setup prevents this from > > working but I don' think it is a dspam limitation. > > It's definitely my set up. I don't use LMTP to pass the message to > dspam, I use a transport called "dspam" that uses pipe. That means > there's no S/LMTP dialog, just the message itself passed as STDIN. If you can show what you've configured to pass mail into dspam, then perhaps someone can tell you how to get that envelope sender address into dspam, too. Wietse I thought I had a while back, but I"m not sure it matters. Right now I am passing mail to dspam via pipe, which means dspam does not know how to handle the envelope-sender as a command-line argument. I need to change this to passing mail to dspam via LMTP. I don't know how exactly, but I hope with some help, I can make it work! That said, here's the current configuration: content_filter=dspam:dspam and in master.cf: dspam unix - n n - 10 pipe flags=Ru user=_dspam argv=/usr/local/bin/dspam -- deliver=innocent --user ${recipient} -i - f $sender -- $recipient dspam is running as a daemon .and re-injects the mail as SMTP to an alternate port. I assume the LMTP setup should look something like: main.cf: content_filter=lmtp:unix:/path/to/dspam --deliver=innocent -- user ${recipient} -i - f $sender -- $recipient and the transport in master.cf becomes unnecessary. I don't know how to handle the command line arguments (or even if I have to), so suggestions, help and especially examples would be most helpful. Thank you! -- Jeff Weinberger http://disruptivemarketing.jeffweinberger.com
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 2:17 PM, mouss wrote: Jeff Weinberger a écrit : On Jan 2, 2009, at 9:20 AM, mouss wrote: Jeff Weinberger a écrit : It's definitely my set up. I don't use LMTP to pass the message to dspam, I use a transport called "dspam" that uses pipe. That means there's no S/LMTP dialog, just the message itself passed as STDIN. so _you_ are not passing the envelope sender to dspam. Consider running dspam in "relay mode": postfix --(LMTP)--> dspam --(SMTP)--> postfix I have to move dspam to use LMTP and then move it to a before-queue why do you want to run it in pre-queue mode? This is not needed and is not simple to setup. Is there a reason why you keep adding yahoo groups after I remove them fro CC? This is starting to annoy me... Sorry!! I was having problems with my messages not posting. I will stop adding :) and by the way, disable the X-DSPAM-Factors header. dspam doesn't encode it, which results in things like: X-DSPAM-Factors: 27, ... a+écrit, 0.01000, and this is not a valid header. OK thanks! If I understand your diagram, then the content_filter would look like: content_filter=lmtp:unix:/path/to/dspam args No. content_filter=lmtp:inet:127.0.0.1:10024 where the 10024 is the same port used in dspam.conf: ServerPort10024 of course, dspam must be running in daemon mode. dspam is running in daemon mode. This makes sense as a setup. The example in the dspam docs for postfix shows content_filter=lmtp:unix:/path/to/dspam.sock which is why I thought unix: instead of inet: is there any difference, other than performance? On a related question (if more broad): some content_filter examples I see use content_filter in main.cf and some as "-o content_filter=..." in master.cf. I understand from prior conversations here that you can't override content filters, they are global. (yes?) So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? and that might pass through the envelope information (I'm not convinced, but if dspam can do it, that would be how). LMTP is similar to SMTP, and dspam can run as an LMTP server (this is configured in dspam.conf). But since dspam can speak LMTP and SMTP dspam has a server and a client. so which speaks what? if we are talking about the server part: $ cd dspam-3.8.0/src $ cat daemon.c .. input = daemon_expect(TTX, "LHLO"); if (input == NULL) goto CLOSE; .. it wants LHLO (which is for LMTP), not HELO or EHLO. so no smtp there. why would an smtpd proxy be hard to set up? It would certainly avoid the bcc issues, etc. I don't understand why you mix pre-queue and bcc. maybe you confuse pre-queue with a "not simple content filter"? I am new to pre-queue filtering and am clearly still confused :) you had asked: why do you want to run it in pre-queue mode? This is not needed and is not simple to setu so I thought it might be hard. It's not important for now...getting dspam working as LMTP will be fine (assuming it passes along all the right information once it works) Thank you!! that I" experiences by having the message run through postfix twice. After reading through SMTPD_PROXY_README, it seems like a bit of a challenge to make it work, but not that hard...what do you think might be difficult? Thanks for all your help - over the course of thi dialog I've learned a lot about postfix and have become more aware of and proficient with parts I knew little about. This has been very helpful. content filter so that this workaround becomes unnecessary, but until I go to make those changes, this will suffice. I'm not completely convinced that dspam will work seamlessly as a before-queue content filter, so I'll have to do some testing to see how well that works and whether it can do what I need and hand fully formed messages with SMTP dialog information back to postfix.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 3:20 PM, mouss wrote: Jeff Weinberger a écrit : content_filter=lmtp:unix:/path/to/dspam args No. content_filter=lmtp:inet:127.0.0.1:10024 where the 10024 is the same port used in dspam.conf: ServerPort10024 of course, dspam must be running in daemon mode. dspam is running in daemon mode. This makes sense as a setup. The example in the dspam docs for postfix shows content_filter=lmtp:unix:/path/to/dspam.sock which is why I thought unix: instead of inet: it's ok to use a unix socket, but it's a socket, not the dspam binary with args. OK, thanks. I will set up dspam to listen on port 10024 - seems to make the most sense. I don't need a localhost:10024 entry in master.cf then? right? is there any difference, other than performance? I wouldn't put performances into the equation without measurements (one should tune where the bottleneck is, not in every small piece). if you use a unix socket, you'll have to make sure it is accessible. In particular, if someday you decide to chroot postfix, you'll need to put the unix socket in the chroot jail. exactly. Thanks On a related question (if more broad): some content_filter examples I see use content_filter in main.cf and some as "-o content_filter=..." in master.cf. I understand from prior conversations here that you can't override content filters, they are global. (yes?) no, they are not global. each smtpd may have its own content_filter. (don't confuse with: "one message, one filter". The latter simply means that postfix won't split a single message into one message per recipient before passing it to the content filter). That makes sense. thank you. So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? I guess an example is better than literature, no? here is a "not uncommon setup": - port 25 is used for "MX" mail (aka inbound mail). it uses the content_filter defined in main.cf right, as I do right now. - port 587 is used for "submission" (authenticated, ...). such mail is scanned for viruses but not for spam (there's not much things a bayesian filter could do here, except in simple setups with a site-wide bayes). so -o is used to set the filter for this service I need to set this up also - seems easy, but is there an example of the localhost:587 master.cf entry somewhere I could start with? - sendmail mail is not filtered, because we "trust" the box (there's no user, ... etc) and we don't want anything blocking such mail. or we use sendmail to reinject mail after filtering, so we don't want to create a loop. for this, we set "-o content_filter=". do you mean the re-injection into postfix? I have "-o content_filter=" there already. I'm re-injecting mail via SMTP, not sendmail... I am new to pre-queue filtering and am clearly still confused :) - content_filter refers to after-the-queue filtering. This means postfix saves the mail on disk, says "ok" to the client, and sometimes after that, postfix passes the message to the filter - proxy_filter refers to pre-queue: postfix keeps the client connected, passed the message to the filter and waits for the filter response before responding to the client. This assumes SMTP, because the message was received via SMTP, so the client wants a single response for the whole message, and not one response per recipient. the pipe method that you were using is an example of a content_filter, and is referred to as a "simple filter" in postfix docs. but a content_filter need not be a pipe. you had asked: why do you want to run it in pre-queue mode? This is not needed and is not simple to setu so I thought it might be hard. and it is. reread what I said about dspam and lmtp... Thank you! It's not important for now...getting dspam working as LMTP will be fine (assuming it passes along all the right information once it works)
Re: issue connecting to mysql after upgrade (issue not postfix)
On Jan 1, 2009, at 4:53 PM, mouss wrote: Jeff Weinberger a écrit : [snip] - try with "hosts = 127.0.0.1" (without "localhost") Tried this - no change. :( ahem. if you do this, you should not hear about a socket. it should use a TCP connection. can you show the errors? OK, now I've taken out the localhost again and there's no more complaining. (not sure why It continued complaining last time...) This is not a postfix issue. This is clearly a MySQL socket issue. I'm pursuing this on the MySQL lists. Thank you! [snip] why do use sender_canonical instead of canonical? rewrite should be consistent, and "your sender is the recipient's recipient"... This is mostly because I use maildrop as the virtual delivery agent for many of the virtual mailboxes. I'm really just testing this, and may end up using canonical instead. But here's my thinking: I have one user who wants a minor change - sounds silly, but gives me a good chance to experiment/learn. I'm rewriting the one address to a specific capitalization. I know I'll be doing more with more users soon. I want to rewrite when mail goes to someone outside my postfix install. canonical_maps would also rewrite inbound mail to that address, which is not bad, but not the desired behavior. So I am trying sender_canonical_maps to get the behavior I want. Then you may want to use smtp_generic_maps instead of canonical.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 4:03 PM, mouss wrote: Jeff Weinberger a écrit : OK, thanks. I will set up dspam to listen on port 10024 - seems to make the most sense. I don't need a localhost:10024 entry in master.cf then? right? no, 10024 will be used by dspam. your postfix should have a 127.0.0.1:10025 to get mail back. perfect thanks! So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? I guess an example is better than literature, no? here is a "not uncommon setup": - port 25 is used for "MX" mail (aka inbound mail). it uses the content_filter defined in main.cf right, as I do right now. - port 587 is used for "submission" (authenticated, ...). such mail is scanned for viruses but not for spam (there's not much things a bayesian filter could do here, except in simple setups with a site-wide bayes). so -o is used to set the filter for this service I need to set this up also - seems easy, but is there an example of the localhost:587 master.cf entry somewhere I could start with? your master.cf should already contain a "submission" service (it's commented out by default). you can add -o conten_filter and other parameters. it didn't - but that's probably because apple modified the example file and took out the submission entry. I found it in the distribution. I'm guessing I should leave my port 25 (smtp) entry to allow submission on that port with authentication (leaving "smtpd_client_restrictions=permit_sasl_authenticated...") - is there any harm in that? - sendmail mail is not filtered, because we "trust" the box (there's no user, ... etc) and we don't want anything blocking such mail. or we use sendmail to reinject mail after filtering, so we don't want to create a loop. for this, we set "-o content_filter=". do you mean the re-injection into postfix? I have "-o content_filter=" there already. I'm re-injecting mail via SMTP, not sendmail... so you already had an example that overrides the content_filter in master.cf ;-) I see that I did... oops ;)
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 5:32 PM, mouss wrote: Jeff Weinberger a écrit : I'm guessing I should leave my port 25 (smtp) entry to allow submission on that port with authentication (leaving "smtpd_client_restrictions=permit_sasl_authenticated...") - is there any harm in that? no. but separating roles makes configuration easier. so encourage users to use 587. ok, thanks - that makes sense and it seems to be working fine for me. dspam isn't working fine accepting messages via LMTP, so I'm taking that over to the dspam list Thank you for your help!
Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
Hi: I would very much appreciate any help, advice, pointers, etc. to resolve an issue I am encountering. I am having a challenge trying to use a mysql table for smtpd_sender_login_maps. Right now I have: In main.cf: smtpd_sender_login_maps=mysql:/path/to/map.cf smtpd_sender_restrictions=reject_sender_login_mismatch, My virtual mailbox table contains the username for authentication (which is also the e-mail address), the password and I am using a text (VARCHAR) field to hold the list of e-mail addresses that each user is allowed to send from. For example, my e-mail is jeff (at) jweinberger.homeip.net. I can send as that e-mail, but I also want to allow sending from someothername (at) jweinberger.homeip.net and from jeff (at) some-other-domain-I- own.tld. so the table row looks like: field username: jeff (at) jweinberger.homeip.net field password: (password) field valid_from: jeff (at) jweinberger.homeip.net, someothername (at) jweinberger.homeip.net, jeff (at) some-other-domain-I-own.tld The select statement in the maps.cf file is "select username from virtual_mailbox_table where (INSTR(valid_from, "%s") > 0)" which successfully (tested outside postfix) looks up the sender address and returns the login name (field: username). I run into problems when more than one login name is permitted to send from a given address. For example, say i include one of my valid addresses as postmaster (at) jweinberger.homeip.net (so I can send from it - mail to it goes into a postmaster mailbox as required). I also want someone else to be able to send from postmaster (at) jweinberger.homeip.net. So the virtual mailbox table would contain: Row 1: field username: jeff (at) jweinberger.homeip.net field password: (password) field valid_from: jeff (at) jweinberger.homeip.net, someothername (at) jweinberger.homeip.net, jeff (at) some-other-domain-I-own.tld, postmaster (at) jweinberger.homeip.net Row 2: field username: someoneelse (at) jweinberger.homeip.net field password: (password) field valid_from: someoneelse (at) jweinberger.homeip.net, yetanothername (at) jweinberger.homeip.net, postmaster (at) jweinberger.homeip.net And when I try to send mail authenticated at jeff (at) jweinberger.homeip.net from postmaster (at) jweinberger.homeip.net it fails with this log entry: postfix/smtpd[83245]: NOQUEUE: reject: RCPT from unknown[10.0.1.1]: 553 5.7.1 : Sender address rejected: not owned by user jeff (at) jweinberger.homeip.net from= to=<--edited--> proto=ESMTP helo=<[10.0.1.7]> The query in this case would return two rows, as both users are allowed to send from that address. According to the description of smtpd_sender_login_maps in http://www.postfix.com/postconf.5.html : "In all cases the result of table lookup must be either "not found" or a list of SASL login names separated by comma and/or whitespace" I conclude that the mysql query is not returning the list in the right form. Since I don't know how mysql calls are implemented in postfix, I don't know what to do to correct this, if it's possible. So my questions: 1) Is my analysis and conclusion (that mysql is not returning the result in the required form) correct? 2) Is there anything I can do to make the result come back in the form postfix needs it? I would like to be able to do this in this way, as I think it makes sense to track which addresses are authorized for each user, rather than the other way around. If there is no direct way to do this, I can build a reverse lookup table that will return the list postfix expects. And of course, if there is any additional information that would help in diagnosing or resolving this, I'd be happy to provide it. Any help, direction, pointers, etc. are much appreciated! Thanks, --Jeff
Re: Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
On Tue Jan 6, 2009 2:42 pm Victor Duchovni wrote: > I know that it is not a good model for the way postfix requires the > query, More stronly, an SQL schema in which multiple data items are stored concatenated in a single table element is a poor schema regardless of the application. This violates fundamental principles of database schema design. Multi-valued elements are stored in separate tables that are joined to the main table. This is not a Postfix requirement, it is basic database design. > but from a logical standpoint, I am trying to this about it > as which addresses is a user allowed to send from. The correct design has a address table which links address objects to user objects, and a user table which holds attribtues of users. To discover the addresses of a user, join the two tables. Implement appropriate indices and forein keys to make the expected queries efficient. > This makes sense > when you think about a user having e-mail service through my server, > and using that to send e-mail from another unrelated valid address then > he/she owns. (validating that is also important, but not in the scope > of this issue). > So I want to associate valid from addresses with the user, not the other > way around. In a correct SQL schema the question is moot, SQL stores relation tuples, there is no notion of which is the primary element in a relation. x R y <=> row (x,y) is present in table R > I understand fully the point of view that postfix takes, asking who is > allowed to send from this e-mail address (more or less masquerade as > this e-mail identity), which makes sense also. Yes, but your schema is poorly designed. A good schema will naturally support a variety of queries that select ether the "x" values for which "x R y" is true for a given "y" or just as easily the converse. > There may be better schema for answering the question I am asking, > but it sounds from your response (I am assuming, possibly dangerously) > That there is no way to do what I want to do without creating another > table in the database, indexed by from address with resuting lists of > users. Is that correct? I am claiming that what you can't be done with your existing schema, perhaps it can. I am claiming that you should change your schema as soon as you can. > Why does postfix reject the mail when the mysql query return one or > several valid SASL users? To solve such questions, divide and conquer: - Use a simple indexed file to store the sasl_sender_login table. Make this work, resolving any issues that you find. - Once SASL sender validation is working without SQL, create an SQL query that given verbatim keys from the indexed file, returns the identical RHS values. Verify with multiple "postmap -q" tests. Once this works, use SQL in the Postfix configuration. The above approach allows you to identify and solve the right problem. -- Viktor. Viktor: Thank you. I agree with all your comments about the database schema, which I have not yet built. I am in testing mode and want to make sure this kind of validation will work as expected and give me the desired results. So if I may, I'd like to focus on getting this to work. I did the testing you suggested before I posted. Here are the tests: I created a hash table (text file then used postmap hash:). The text file had lines like this: sender_address1 sasl_owner sender_address2 sasl_owner2, sasl_owner3, sasl_owner4 and so on, for the several addresses I tested. I then used postmap -q to verify that the lookup returned the correct values. As speficied in the documentation for smtpd_sender_login_maps, it returned one single SASL user name when only one user is authorized to send from that from address and a string of comma-separated names when multiple users are authorized to send from that from address. I then added the line: smtpd_sender_login_maps=hash:/path/to/map to my main.cf and send a few messages. Postfix correctly allowed and rejected all of the test messaages, and the logs showed the correct reason for the rejection, and no log entries showing a successful match. I then, again just to test, added a field to my virtual users table to hold authorized addresses, and wrote the query noted above into a mysql_sender_login_maps.cf file. I used postmap -q to verify that the results of the query were correct and were exactly the same as the results received when I used postmap - q on the hash: file. They all were identical for the same lookup keys. I then changed the main.cf line to: smtpd_sender_login_maps=hash:/path/to/mysql_sender_login_maps.cf and tried the same series of test messages. All of the test messages failed. The ones where the lookup produced the same comma-separated line as with the hash: file, and the ones where the lookup produced a single result. All were rejected (as noted in the log entry I posted previously) with the reason that the from address was
Re: Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
On Jan 6, 2009, at 5:59 PM, Wietse Venema wrote: Jeff Weinberger: I then added the line: smtpd_sender_login_maps=hash:/path/to/map to my main.cf and send a few messages. Postfix correctly allowed and rejected all of the test messaages, and the logs showed the correct reason for the rejection, and no log entries showing a successful match. I then, again just to test, added a field to my virtual users table to hold authorized addresses, and wrote the query noted above into a mysql_sender_login_maps.cf file. I used postmap -q to verify that the results of the query were correct and were exactly the same as the results received when I used postmap - q on the hash: file. They all were identical for the same lookup keys. smtpd does the same lookups as "postmap -q". If the result is different than when you run "postmap -q" by hand, then it is almost certain that you are using a different search key than Postfix uses. Postfix does the lookups as documented in the postconf(5) manual page: smtpd_sender_login_maps (default: empty) Optional lookup table with the SASL login names that own sender (MAIL FROM) addresses. Specify zero or more "type:table" lookup tables. With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, the following search operations are done with a sender address of u...@domain: 1) u...@domain This table lookup is always done and has the highest precedence. 2) user This table lookup is done only when the domain part of the sender address matches $myorigin, $mydestination, $inet_inter- faces or $proxy_interfaces. 3) @domain This table lookup is done last and has the lowest precedence. You can see what lookups Postfix does by setting the debug_peer_list parameter in main.cf. For example: # postconf -e debug_peer_list=static:all # postfix reload Wietse Wietse Thank you very much for your help. I just responded to Viktor as well, and plead stupid. I just re-ran all the same tests (by hand this time) and everything worked. All postmap-q commands gave the correct results, and all messages were accepted or rejected as expected. I checked the scripts I used earlier for logical errors and typos, but found none. so I have no idea why I was getting odd results. Never-the-less, all works now. I thank you and Victor for your generous help. --Jeff
how to specify an over-ride in master.cf that contains whitespace
Hi: Yet another question I hope I can impose upon your help for... I am testing sender restrictions and have defined an alternate submission entry in master.cf for this purpose (and not to disrupt other users while I test). I want to test the check_sender_access which requires the form "check_sender_access type:table" which includes whitespace, which is not permitted in master.cf According to the master(5) documentation: do not specify whitespace around the "=". In parameter values, either avoid whitespace altogether, use commas instead of spaces, or consider overrides like "-o name=$override_parameter" with $over- ride_parameter set in main.cf. So will this work: main.cf: $my_test_sender_restrictions=check_sender_access pcre:/path/to/ file.pcre master.cf -o smtpd_sender_restrictions= $my_test_sender_restrictions,reject_sender_login_mismatch,. or am I missing something? Thank you! --Jeff
"forcing" authenticated users to use port 587?
Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? Thank you for any help and/or advice! --Jeff
Re: "forcing" authenticated users to use port 587?
On Jan 8, 2009, at 5:49 AM, Jorey Bump wrote: Jeff Weinberger wrote, at 01/08/2009 12:10 AM: Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Yes, you can simply set smtpd_sasl_auth_enable = no (which is the default, so you could also remove the line, but being explicit might be more helpful in this case). You can also remove permit_sasl_authenticated from smtpd_*_restrictions, but it might be wise to leave it in place for the time being (it shouldn't cause any problems). Your submission service in master.cf should already have -o smtpd_sasl_auth_enable=yes in it. Keep in mind, however, that some users will still be able to use port 25 to send messages to domains that the server accepts mail for. To them, it may seem that relaying works inconsistently. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? The decision to restrict mail submission to port 587 depends on your needs. I manage some environments where this is enforced. I actually like the separation, but it sometimes requires additional support for legacy clients (achieved in various ways). In other environments with a more diverse and general population, I continue to allow submission on port 25, but only with mechanisms that are considered secure. You'll probably want to begin with this arrangement, as you are suggesting. It's kinder to your users, if you're not in any rush. The important thing is that you're opening port 587 (with sane settings) to support road warriors and users whose ISPs block outgoing connections to port 25. This move benefits them as much (if not more) as you. Thank you for your help and insight.!! I'm glad to hear that this is a fairly common option and one that can be supported, even if with some hoop-jumping. As far as how to make it happen... Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Thanks! --Jeff
Re: "forcing" authenticated users to use port 587?
On Thu, 08 Jan 2009 09:53:45 -0500, Jorey Bump wrote: > Jeff Weinberger wrote, at 01/08/2009 09:27 AM: > >> Setting smtpd_sasl_auth_enable = no would mean that no authentication is >> required on port 25, but if I understand it correctly, it wouldn't >> actually stop an authenticated user from sending mail through port 25. >> If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = >> no, would postfix refuse the connection? > > Actually, smtpd_sasl_auth_enable = no means that authentication is not > enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/EHLO. > Attempts to authenticate will generate an error. Most modern clients are > intelligent enough to detect the absence of AUTH and will not attempt to > authenticate. Good ones will abort and notify the user. Bad ones might > attempt to continue, in case the server will still accept the message. > If the domain is a destination your server handles, it will probably > accept the message, otherwise it will reject it. > >> In the final step of my scenario, that's the behavior I want to achieve. >> Will that simple step work? > > Yes. You can completely disable submission on port 25 and prevent > relaying to destinations you don't accept by hosts outside of mynetworks. Jory: Thanks again! So it looks like it's as simple as smtpd_sasl_auth_enable = no for port 25, and then making sure everything else is set so that mail coming in on port 25 has to be for one of my domains or it's rejected. Thanks! I appreciate the help!
Re: "forcing" authenticated users to use port 587?
On Jan 8, 2009, at 6:53 AM, Jorey Bump wrote: Jeff Weinberger wrote, at 01/08/2009 09:27 AM: Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? Actually, smtpd_sasl_auth_enable = no means that authentication is not enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/ EHLO. Attempts to authenticate will generate an error. Most modern clients are intelligent enough to detect the absence of AUTH and will not attempt to authenticate. Good ones will abort and notify the user. Bad ones might attempt to continue, in case the server will still accept the message. If the domain is a destination your server handles, it will probably accept the message, otherwise it will reject it. In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Thank you an thank you to Chris for your help on this! I just have two, maybe obvious questionsif I may; I noticed that on several occasions, and in the default master.cf: -o milter_macro_daemon_name=ORIGINATING is suggested for the submission service. I'm not familiar with Milters and can't find information on what this is or what this does (at least in my search of the docs). Can you offer any pointers to where I can learn more specifics about milter macro daemons and this specific one? Also you noted: In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Does smtpd_sasl_auth_enable = no completely disable submission and prevent relaying for hosts I don't accept? or is there more I have to make sure I do? thank you again! --Jeff
Question about reject_unauthenticated_sender_login_mism atch
Hi: This question is just a request for information on this... I currently use reject_sender_login_mismatch in my smtpd_sender_restrictions as an added precaution against someone sending undesirable mail. I see that I can also use reject_unauthenticated_sender_login_mismatch, but I don't understand how this would work. reject_sender_login_mismatch checks the from address against smtpd_sender_login_maps to be sure that the MAIL FROM address is owned by the SASL-authenticated sender. But with reject_unauthenticated_sender_login_mismatch, there is no SASL-authenticated sender. http://www.postfix.com/postconf.5.html says that reject_unauthenticated_sender_login_mismatch "Enforces the reject_sender_login_mismatch restriction for unauthenticated clients only" (and nothing more) All of that to get to my question: What does reject_unauthenticated_sender_login_mismatch check the MAIL FROM address against? Or does it just check the smtpd_sender_login_maps for a valid MAIL FROM address (regardless of ownership)? (yes, I'm trying to figure out if using this in my smtpd_sender_restrictions would help and how it might do so) Thank you!! --Jeff
Re: Question about reject_unauthenticated_sender_login_mismatch
Viktor Duchovni wrote: On Mon, Jan 12, 2009 at 01:25:38PM -0800, Jeff Weinberger wrote: reject_sender_login_mismatch checks the from address against smtpd_sender_login_maps to be sure that the MAIL FROM address is owned by the SASL-authenticated sender. But with reject_unauthenticated_sender_login_mismatch, there is no SASL-authenticated sender. This subsumes the functionality of both: reject_authenticated_sender_login_mismatch, reject_unauthenticated_sender_login_mismatch OK, I missed the first one in the doc, so it makes sense. if the session is authenticated the first test is applied, otherwise the second test is applied. http://www.postfix.com/postconf.5.html says that reject_unauthenticated_sender_login_mismatch "Enforces the reject_sender_login_mismatch restriction for unauthenticated clients only" (and nothing more) All of that to get to my question: What does reject_unauthenticated_sender_login_mismatch check the MAIL FROM address against? The smtpd_sender_login_maps table. Sorry, I mis-asked the question. When reject_authenticated_sender_login_mismatch is specified, postfix takes the MAIL FROM address, looks it up in the smtpd_sender_login_maps table, and checks to make sure the authenticated sender is in there and the MAIL FROM address is owned by the authenticated sender. So Or does it just check the smtpd_sender_login_maps for a valid MAIL FROM address (regardless of ownership)? s/valid// If an address is found in the table, and the sender is not authenticated, the message is rejected. When a sender is not authenticated, and reject_unauthenticated_sender_login_mismatch is specified, postfix takes the MAIL FROM address, looks it up in smtpd_sender_login_maps and if it's found, the message is rejected? Essentially the lookup is just for the existence of the MAIL FROM address in the smtpd_sender_login_maps table? Am I then correct in concluding that with: smtpd_sender_restrictions = permit_sasl_authenticated, reject_authenticated_sender_login_mismatch, reject that the permit_sasl_autheticated obviates the need for reject_unauthenticated_sender_login_mismatch? (as there would never be an unauthenticated sender permitted...) And am I also correct in concluding that is unauthenticated senders were allowed (as they would have to be for smtpd to accept messages from the internet), that reject_unauthenticated_sender_login_mismatch would prevent any non-authenticated sender from sending a message from (with MAIL FROM) any address listed in my smtpd_sender_login_maps? (yes, I'm trying to figure out if using this in my smtpd_sender_restrictions would help and how it might do so) If you are already using the combined restriction, there is no point in adding either of the constituent building-block restrictions. That makes perfect sense. If you want to restrict your policy to either the authenticated, or the unauthenticatd case, then replace the combined restriction with the appropriate more specific restriction. As you see, I'm more interested in whether reject_unauthenticated_sender_login_mismatch makes sense at all for my setup and if so, in which context. If my two conclusions above are correct, it makes sense on the general access service, but not on the submission service. Thank you so much for your help!! -- Viktor.
holding messages for one address or one domain in the queue?
This may seem like an odd question, but I need to find a way to suspend delivery of mail to one account or one domain for a short period of time to allow me to do a bit of maintenance. As it stands now, I use maildrop as my delivery transport for virtual mailboxes. Is there a way to tell postfix to hold the mail in its queue until I tell it I'm ready? Is this as simple as having maildrop return a temporary failure code? and if that happens, postfix will retry at certain intervals (or on postqueue -f) right? And if that is a good way to do it, what return code should maildrop return? Or is there a better way? Thank you!
Re: holding messages for one address or one domain in the queue?
On Jan 14, 2009, at 3:53 PM, Roderick A. Anderson wrote: Jeff Weinberger wrote: This may seem like an odd question, but I need to find a way to suspend delivery of mail to one account or one domain for a short period of time to allow me to do a bit of maintenance. As it stands now, I use maildrop as my delivery transport for virtual mailboxes. Is there a way to tell postfix to hold the mail in its queue until I tell it I'm ready? I've used a pretty simple trick of putting the domain in the header_checks.regexp file. header_checks.regexp /^To: @example.com/HOLD Rod nice trick! - thanks! -- Is this as simple as having maildrop return a temporary failure code? and if that happens, postfix will retry at certain intervals (or on postqueue -f) right? And if that is a good way to do it, what return code should maildrop return? Or is there a better way? Thank you!
Re: Question about reject_unauthenticated_sender_login_mismatch (additional information)
Viktor Wrote: On Thu, Jan 15, 2009 at 10:01:51PM +0100, mouss wrote: > jeff_homeip a ?crit : > > [snip] > > When I added this back, all worked fine. If I remove this one restriction > > (check_sender_access), I can no longer send. > > > > is this check_sender_access, because it's not rejecting the sender, allowing it somehow? > > > > no. it's more probable that you have errors in your config. > I this it's absolutely certain that I had errors in my config. As you noticed, I have been having a challenge trying to isolate and fix them. > if you think you have a problem with one particular configuration, then > we need to see that configuration, so > > 1) configure postfix to reproduce the problem > 2) restart postfix > 3) from now, don't change any setting until the end of this procedure > 4) reproduce the problem (test...) > 5) if you succeed, send us the > -- contents of master.cf > -- the output of 'postconf -n' > -- the contents of main.cf (to see "custom" variables) 6) "postmap -q - " output for all relevant keys in all relevant tables. 7) verbose logging from the smtpd(8) showing the events that lead up to reject restriction. Configure via "debug_peer_list" or "-v" entry in master.cf. It is enough to report just 10-20 lines of logging above the "reject" event, that demonstrate which restrictions is being processed and associated table lookup keys and results. As I noted earlier, I restored my main.cf and master.cf from backup (a known working version) and started over. I ran these tests with that version and found no problems. I then changed the configurations to the desired end-point and ran these (and a few other) tests again. Again no problems. So I was not able to reproduce this. I have to conclude that I took interim steps on the way to the desired state, and one of those resulted in the errors I observed. Since I did not document my steps, only my goal, I cannot reproduce each one, and since I cannot find the combination that produced the error, I have to conclude that I did something seriously wrong at some point. So I must apologize - I have asked you to help chase an issue that seems to have been just an interim error. I appreciate your help and effort, but I am sorry that it appears unnecessary. (of course, if it recurs, I'll run these tests again, and if I can reproduce it, post all the information here) I now have it working, as far as I can tell, as I want. The goal was to have a submission service that forces authentication and requires that authenticated users only send from addresses they own. So I now have: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_restrictions= $ 587_master_sender_restrictions ,reject_sender_login_mismatch,permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING with, in main.cf: 587_master_sender_restrictions=check_sender_access pcre:/etc/postfix/ smtpd_sender_restrictions.pcre and smtpd_sender_restrictions.pcre containing one line: /^(.*)/ PREPEND X-Envelope-Sender: <${1}> I was concerned that the "match" on PREPEND would obviate the further sender_restrictions, but that appears not to be the case, in limited testing so far. The recipient_restrictions are solely meant to avoid the many checks ( e.g. RBL, unauth_pipelining, etc.) in my main.cf for my smtp service. This appears to work. I am of course, open to any and all suggestions on how this can be improved. Again, sorry for dragging you down an dead-end path, but thank you for your help - I've learned a lot along the way. --Jeff
Question on sendmail submission and master.cf -o overrides
Hi: I am hoping someone can offer help in determining this information about the specifics of how sendmail submits mail. I have three different services configured in master.cf to accept mail: 1) the regular smtpd service on port 25, 2) a submission service for authenticated clients, and 3) a reinjection service (localhost: 10026) to accept mail after an after-queue content filter (which is specified as an - o override on the port 25 service in master.cf, not in main.cf). I am about to add a different after-queue content filter to the submission service (also via an -o override in master.cf), and this content filter re-injects mail via the sendmail command. There is no content_filter specified in main.cf. In this configuration, when mail is submitted via the sendmail command, will the content filter specified on the port 25 service apply? or will postfix only pay attention to the settings in main.cf for the purposes of transferring that mail? I suppose the more general question is which set of configuration options is mail submitted via the sendmail command subject to? (yes, I read the sendmail(1) documentation and did not find this information. The architecture documentation indicates only that it is subject to pretty much anything that local submission is subject to, but it's not clear what that is). Any help or pointers are very much appreciated! Thanks, --Jeff
Re: Question on sendmail submission and master.cf -o overrides
Viktor Wrote: Date: Tue, 20 Jan 2009 22:26:23 -0500 From: Victor Duchovni Subject: Re: Question on sendmail submission and master.cf -o overrides On Tue, Jan 20, 2009 at 07:11:16PM -0800, Jeff Weinberger wrote: I am hoping someone can offer help in determining this information about the specifics of how sendmail submits mail. The postdrop(1) helper places the mail in the maildrop sub-directory of the Postfix queue. The pickup(8) daemon asynchronously injects mail into the "incoming" queue (via cleanup(8)) one message at a time There is no content_filter specified in main.cf. In this configuration, when mail is submitted via the sendmail command, will the content filter specified on the port 25 service apply? or will postfix only pay attention to the settings in main.cf for the purposes of transferring that mail? Local submission via sendmail(1) does not use SMTP, so the smtpd(8) service on port 25 never sees the mail. Ergo, settings there do not apply. I suppose the more general question is which set of configuration options is mail submitted via the sendmail command subject to? 1. "-o" options in the pickup(8) service master.cf(5) entry. 2. main.cf parameter settings Thank you . Make sense. If I wanted to change any of the pickup(8) options, I'd need to define an alternate pickup service (not likely to do this). (yes, I read the sendmail(1) documentation and did not find this information. The architecture documentation indicates only that it is subject to pretty much anything that local submission is subject to, but it's not clear what that is). Submission via sendmail(1) *is* "local submission". The latter is a term of art for the former. http://www.postfix.org/OVERVIEW.html#receiving o Local submissions are received with the Postfix sendmail(1) compatibility command, and are queued in the maildrop queue by the privileged postdrop(1) command. This arrangement even works while the Postfix mail system is not running. The local pickup(8) server picks up local submissions, enforces some sanity checks to protect Postfix, and gives the sender, recipients and message content to the cleanup(8) server. - -- Viktor. Thank you for your help - this is very clear.
Redirect all mail from one domain to the same u...@otherdomain?
Hi: I would appreciate any advice anyone can offer on how best to achieve this behavior: I am trying to figure out the best way to map one domain to another with the same users...precisely the behavior I am trying to achieve is: when mail is sent (from outside, or from another user within my postfix installation) to u...@domain1.tld I want it redirected to u...@domain2.tld - in otherwords, the user is preserved, but the domain is translated/ rewritten. To be more specific: us...@domain1.tld gets re-routed to us...@domain2.tld us...@domain1.tld gets re-routed to us...@domain2.tld and so on. My initial guess is to use recipient_canonical_maps and use a pcre map: /^(.*)@domain1.tld/ {$1)@domain2.tld I don't see a way to achieve this with alias_maps and header_checks (with action REDIRECT) would miss messages sent to u...@domain1.tld where that is not the To: or Cc: address (such as list mail). Really, I am just checking with experts more knowledgeable than I whether I have chosen a good (or the best) way to achieve this, or if there is a better way. Any advice and help are much appreciated! Thanks, --Jeff -- Jeff Weinberger http://disruptivemarketing.jeffweinberger.com
Re: Redirect all mail from one domain to the same u...@otherdomain?
jeff_homeip a écrit : [snip] that creates some complications...and might be too difficult a script and a Makefile... or sql as below: but why not use wildcard virtual aliases? You noted below that they break recipient validations. Do you mean that smtp_recipient_restrictions won't work? at all or parts? no, it's not about smtpd restrictions. it's about rejecting mail to invalid recipients. Wildcard virtual aliases seems like the best waybut I want to understand the implications on everything esle before I proceed. Thanks! The reason is that if you use @example.com @example.org then this breaks recipient validation: smtpd will accept anything^example.com, then at delivery time, the user won't be found and a bounce will be generated. in short, you become a source of backscatter (you send bounces to innocents whose addresses were forged by spammers) Unless I don't bounce unknown addresses and you'd do what with these? if you have a catchall, it's ok. but you should not discard mail (people do mistype addresses some time, so it's not just spammers trying invalid addresses). I use a catchall for some domains instead of rejecting unknown recipients, for exactly that reason. I find about 2-3% of catchall mai is user errors (like mis-spellings) rather than spam. So in this case, I can use a wildcard catchall. So an alias map of: @domain1.tld @domain2.tld will produce the expected result of anyuser @ domain1.tld being redirected to the same user (anyuser) @ domain2.tld? That would be by far the easiest to do in my setup. you can generate the individual mappings with a script. alternatively, if you store users in sql, you can use sql statements to generate these "on the fly". examples have been posted multiple times to the list (a long time ago, that said, but you may be lucky...). it would be something like: if (%d=3D'domain1.com') then select %...@domain2..com from virtual_alias else select alias from virtual_alias where address=3D%s (that's not quite right in the syntax, but you get the idea). This wont' work, as I'd have to write a special select clause for each domain I want to work this way. assuming you have a User table containing valid email addresses and a AliasDomain table containing (alias, destination) domains: select User.user from AliasDomain, User where AliasDomain.alias =3D '%d' AND User.user =3D CONCAT('%u', '@', AliasDomain.destination) you can avoid the CONCAT inside the "search" if you split your emails in (user, domain) columns like I do. in which case, the query becomes select CONCAT(User.user, '@', User.domain) where AliasDomain.alias =3D '%d' AND AliasDomain.destination =3D User.domain AND User.user =3D '%u' of course, this works for "1 depth" alias domains (it doesn't work if example.net is an alis for example.org which is in turn an alias of example.com). but this should be enough in most cases. This is helpful, but I still need the query to take all the other alias domains into account. So, I need the IF condition, or a second map. Thank you for your help...it's informative as always! if the wildcard alias will produce the result I need then this is resolved. -- Jeff Weinberger http://disruptivemarketing.jeffweinberger.com
allowing outside users access to mailman lists
I am hoping that this is something fairly simple that I am missing I have a few lists on a mailman server that I run. Until recently, only authenticated users (those who have actual accounts on my IMAP/Virtual mailboxes server and can authenticate via SASL). Now I want to allow certain users who are not authenticated (i. e. they are outside my server and domains) to send mail to those lists. as far as I can tell, mailman would allow this (I've made them list owners). But when they try, I'm getting this in my mail log: Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from ns1.siteground235.com[75.125.60.15]: 554 5.7.1 < myl...@lists.mylistserver.com>: Relay access denied; from=< otheru...@otherdomain.com> to= proto=ESMTP helo= (names changed to protect the innocent, no data changes of relevance) I've tried a few changes (I'd log them here, if I had documented them, sorry) that I thought would have taken away the authentication requirement, to no avail. this might also me an issue of the HELO domain and the FROM domain being different (which is OK, in this case, but not sure how I have prohibited it, so don't know what to change. The goal is to allow outside users without opening up the mailserver (or the mailman server) to spam, etc... FYI: the transport for everything to lists.mylistserver.com is mailman: and lists.mylistserver.com is in $relay_domains Here are snips from my master.cf that show the path of the message (in smtp, into amavisd content filter, out of amavisd on 10026 and to mailman) smtp inet n - n - - smtpd -o recipient_bcc_maps=mysql:/etc/postfix/mysql_recipient_bcc_maps.cf -o receive_override_options=no_address_mappings -o content_filter=amavisfeedl:[127.0.0.1]:10027 amavisfeedl unix- - n- 2 lmtp -o lmtp_data_done_timeout=1200 -o lmtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 localhost:10026 inet n - n - - smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks -o smtpd_helo_restrictions= -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,permit_auth_destinations,reject -o mynetworks=127.0.0.0/8 -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o smtpd_delay_reject=no -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters -o local_header_rewrite_clients= mailman unix - n n - 10 pipe flags=FR user=_mailman argv=/usr/local/mailman/postfix-to-mailman.py ${nexthop} ${user} and my `postconf -n` output is below. I'm running Postfix 2.6.5 on Mac OS/X (client) 10.5.8 Any help is appreciated and I will do my best to answer any questions. Thank you! --Jeff -`postconf -n` output alias_database = mysql:/etc/postfix/mysql_alias_maps.cf alias_maps = mysql:/etc/postfix/mysql_alias_maps.cf broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 default_verp_delimiters = += disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_checks.pcre html_directory = /etc/postfix/html inet_interfaces = all local_recipient_maps = luser_relay = ot...@jeffweinberger.com mail_owner = _postfix mailbox_size_limit = 0 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 0 mydestination = mysql:/etc/postfix/mysql_mydestination_maps.cf mydomain = jweinberger.homeip.net myhostname = jweinberger.homeip.net mynetworks = 127.0.0.0/8, !10.0.1.1, !10.0.1.210, 10.0.1.0/28 newaliases_path = /usr/bin/newaliases queue_directory = /private/var/spool/postfix readme_directory = /usr/share/doc/postfix recipient_delimiter = + relay_domains = $mydestination, mysql:/etc/postfix/ mysql_relay_domain_maps.cf relay_recipient_maps = relayhost = outbound.mailhop.org sample_directory = /usr/share/doc/postfix/examples sender_canonical_maps = mysql:/etc/postfix/mysql_sender_canonical_maps.cf sendmail_path = /usr/sbin/sendmail setgid_group = _postdrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = smtp_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem smtp_tls_cert_file = /etc/postfix/certs/postfix-cert.pem smtp_tls_key_file = /etc/postfix/certs/postfix-key.pem smtp_tls_loglevel = 1 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache smtp_use_tls = yes smtpd_data_restrictions
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, mouss wrote: > > Jeff Weinberger a �crit : > > I am hoping that this is something fairly simple that I am missing > > > > I have a few lists on a mailman server that I run. Until recently, only > > authenticated users (those who have actual accounts on my IMAP/Virtual > > mailboxes server and can authenticate via SASL). Now I want to allow > > certain users who are not authenticated (i. e. they are outside my > > server and domains) to send mail to those lists. > > > > as far as I can tell, mailman would allow this (I've made them list > > owners). But when they try, I'm getting this in my mail log: > > > > Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from > > ns1.siteground235.com <http://ns1.siteground235.com/>[75.125.60.15]: 554 > > 5.7.1 > <mailto:myl...@...>>: Relay access denied; > > from=mailto:otheru...@...>> > > to= > <mailto:myl...@...>> proto=ESMTP > > helo=http://serv01.siteground235.com/>> > > > > you need to add lists.mylistserver.com to one (and only one) of > mydestination, relay_domains or virtual_maibox_domains. >From my original post: FYI: the transport for everything to lists.mylistserver.com is mailman: and lists.mylistserver.com is in $relay_domains which means that it is not working as you suggest it should Any suggestions on where else to look? > > > [snip] >
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wrote: > > Jeff Weinberger: > [ Charset UTF-8 unsupported, converting... ] > > --- In postfix-us...@yahoogroups.com, mouss wrote: > > > > > > Jeff Weinberger a ?crit : > > > > I am hoping that this is something fairly simple that I am missing > > > > > > > > I have a few lists on a mailman server that I run. Until recently, only > > > > authenticated users (those who have actual accounts on my IMAP/Virtual > > > > mailboxes server and can authenticate via SASL). Now I want to allow > > > > certain users who are not authenticated (i. e. they are outside my > > > > server and domains) to send mail to those lists. > > > > > > > > as far as I can tell, mailman would allow this (I've made them list > > > > owners). But when they try, I'm getting this in my mail log: > > > > > > > > Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from > > > > ns1.siteground235.com <http://ns1.siteground235.com/>[75.125.60.15]: 554 > > > > 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 > # postconf virtual_alias_domains > # postconf mailbox_domains > # postconf mydestination > > Wietse > 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 I then checked with `postmap -q "maill...@lists.mylistserver.com" mysql:/etc/postfix/mysql_relay_domain_maps.cf` and it showed up fine. 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. I have tried it where postfix returns the domain ("lists.mylistserver.com" without the quotes) 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. Thanks!
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wrote: > > Jeff Weinberger: > > > > > > Jeff Weinberger: > > > [ Charset UTF-8 unsupported, converting... ] > > > > --- In postfix-us...@yahoogroups.com, mouss wrote: > > > > > > > > > > Jeff Weinberger a ?crit : > > > > > > I am hoping that this is something fairly simple that I am > > missing > > > > > > > > > > > > I have a few lists on a mailman server that I run. Until recently, > > only > > > > > > authenticated users (those who have actual accounts on my > > IMAP/Virtual > > > > > > mailboxes server and can authenticate via SASL). Now I want to allow > > > > > > certain users who are not authenticated (i. e. they are outside my > > > > > > server and domains) to send mail to those lists. > > > > > > > > > > > > as far as I can tell, mailman would allow this (I've made them list > > > > > > owners). But when they try, I'm getting this in my mail log: > > > > > > > > > > > > Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from > > > > > > ns1.siteground235.com <http://ns1.siteground235.com/>[75.125.60.15]: > > 554 > > > > > > 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 > > > # postconf virtual_alias_domains > > > # postconf mailbox_domains > > > # postconf mydestination > > > > > > Wietse > > > > > > > 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 > > > > I then checked with `postmap -q "maill...@..." > > mysql:/etc/postfix/mysql_relay_domain_maps.cf` and it showed up fine. > > Sorry, that is incorrect. > > As documented, Postfix searches relay_domains for the DOMAIN NAME > not the email address. > http://www.postfix.org/postconf.5.html#relay_domains > > Also, as documented, relay_domains lookup ignores the result value, > it only cares about existence. > http://www.postfix.org/postconf.5.html#relay_domains > > Finally, as documented, don't use MySQL databases BEFORE you have things > working with simple main.cf lists or hash tables. > http://www.postfix.org/DATABASE_README.html > > Wietse > OK, point taken. I have now, based on your suggestion tested the following: `postmap -q "maill...@lists.mylistserver.com" mysql:/etc/postfix/ mysql_relay_domain_maps.cf` and `postmap -q "lists.mylistserver.com" mysql:/etc/postfix/ mysql_relay_domain_maps.cf` Both returned successful results. I tested this extensively with the domains typed in to mail.cf before I moved to mysql queries, but at your suggestion, I tested this also. I changed main.cf so the only "relay_domains" entry is: relay_domains=lists.mylistserver.com I executed `sudo postfix reload` and the confirmed the setting with `postconf -n` The result did not change. I received the same NOQUEUE message in my logs (it is identical in every character to the one I posted previously, with the exception of the timestamp). I suspect you may have other suggestions as to how to address the relay domain issue, and I would appreciate them, and will do my best to try them. However, I am coming to believe that the issue is not in the relay domains, but rather in a sender or recipient restriction. I believe this because whenever I send to any address within lists.mylistserver.com from a user who is SASL-authenticated on my server, the message goes successfully. When I send to any address within lists.mylistserver.com from any user (address) outside my server (not authenticated on my server, simply sending to it), this error occurs. I think in my attempts to ensure tight security on the server, I've disallowed external senders to lists, but I can't see how exactly. Any help on the question on how I might be disallowing external senders to *...@lists.mylistserver.com would be much appreciated. Thank you.
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wrote: > > Jeff Weinberger: > > I changed main.cf so the only "relay_domains" entry is: > > > > relay_domains=lists.mylistserver.com > > You need to verify this with the command > > postconf -n > > It's no good posting unverified cut-and-paste to the mailing list. > > Wietse > So you want me to post the entire `postconf -n` again? copying and pasting the one relevant line and stating clearly that I verified it exactly that way doesn't suffice? How do you suggest I verify my cut-and-paste? I'll be happy to do so, if it will help us move beyond log discussions and to the issue at handthat said: I executed `postconf -n | grep relay_domains` and the result was: relay_domains=lists.mylistserver.com I made no other changes other than to relay_domains as suggested. I am hoping that someone can please help with the authenticated user issue and either help me determine why this happens or explain why my interpretation of this is wrong? The crux of this issue is there To recap: Authenticated (SASL) senders can send successfully, outside users can't. My interpretation is the problem lies in there. as that is the only thing that makes any difference at all. I need help figuring out what would cause that, or an explanation of why my interpretation is wrong. I would appreciate some help on this, if anyone has any ideas.
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 1:36 PM, Wietse Venema wrote: > Jeff Weinberger: >> > Jeff Weinberger: >> > > I changed main.cf so the only "relay_domains" entry is: >> > > >> > > relay_domains=lists.mylistserver.com >> > >> > You need to verify this with the command >> > >> > postconf -n >> > >> > It's no good posting unverified cut-and-paste to the mailing list. >> > >> > Wietse >> > >> >> So you want me to post the entire `postconf -n` again? copying and pasting > > I was trying to help, but posting tidbits out of their context > makes support difficult. > > Wietse > I get that - but I'm not sure what would help. I posted my entire `postconf -n` then I posted the result of `postconf -n | grep relay_domains` (as that's the only change I've been making - especially to be sure that no other change could possibly affect this). If there's something else that will help or a different way you want me to post information to help you understand it better, I'm glad to - just tell me what will help and I'll post it here. You've made it clear I'm posting the wrong thing - but I don't know what the "right" thing is
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 2:38 PM, Stan Hoeppner wrote: > Jeff Weinberger put forth on 1/28/2010 4:18 PM: > >> You've made it clear I'm posting the wrong thing - but I don't know >> what the "right" thing is > > Sorry to but in Wietse. > > Jeff, paste all of postconf -n output and obfuscate any sensitive information > in > it such as hostnames or IP addresses that you don't want made public here. > Wietse may not know what the "right" thing is until he sees all of postconf > -n. > There are interdependencies between various settings and often problems can't > be identified without seeing the big picture. > > If you read the list welcome message and posting instructions you'd see that > "postconf -n" output is a standard requirement here for receiving help. You > are > not being asked to provide anything beyond what everyone else is asked to > provide. If you want assistance, we need to see the data. It's that's > simple. > > Cooperate and everything will work out fine, you'll have a solution. > > Best regards. > > -- > Stan > Stan - I can't speak for Wietse, but thanks for butting in. I posted it in the original message, and only changed the one item on the presumption that when diagnosing an issue, making other, non-controlled changes just confuses things. That said, here's the latest, still not working, `postconf -n` complete output, If it got lost somewhere, I"m running Postfix 2.6.5 on Mac OS/X (client) 10.5.8 Again, if there is anything else I can post that will help, please let me know and I will be glad to do so. -`postconf -n` output alias_database = mysql:/etc/postfix/mysql_alias_maps.cf alias_maps = mysql:/etc/postfix/mysql_alias_maps.cf broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 default_verp_delimiters = += disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_checks.pcre html_directory = /etc/postfix/html inet_interfaces = all local_recipient_maps = luser_relay = ot...@jeffweinberger.com mail_owner = _postfix mailbox_size_limit = 0 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 0 mydestination = mysql:/etc/postfix/mysql_mydestination_maps.cf mydomain = jweinberger.homeip.net myhostname = jweinberger.homeip.net mynetworks = 127.0.0.0/8, !10.0.1.1, !10.0.1.210, 10.0.1.0/28 newaliases_path = /usr/bin/newaliases queue_directory = /private/var/spool/postfix readme_directory = /usr/share/doc/postfix recipient_delimiter = + relay_domains = lists.mylistserver.com relay_recipient_maps = relayhost = outbound.mailhop.org sample_directory = /usr/share/doc/postfix/examples sender_canonical_maps = mysql:/etc/postfix/mysql_sender_canonical_maps.cf sendmail_path = /usr/sbin/sendmail setgid_group = _postdrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = smtp_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem smtp_tls_cert_file = /etc/postfix/certs/postfix-cert.pem smtp_tls_key_file = /etc/postfix/certs/postfix-key.pem smtp_tls_loglevel = 1 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache smtp_use_tls = yes smtpd_data_restrictions = reject_unauth_pipelining smtpd_etrn_restrictions = permit_mynetworks, reject smtpd_helo_required = yes smtpd_recipient_restrictions = check_recipient_access mysql:/etc/postfix/mysql_check_recipient_access_maps.cf, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client list.dsbl.org, reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:2501, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_security_options = noanonymous smtpd_sender_login_maps = mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/smtpd_sender_restrictions.pcre smtpd_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem smtpd_tls_cert_file = /etc/postfix/certs/postfix-cert.pem smtpd_tls_key_file = /etc/postfix/certs/postfix-key.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache smtpd_use_tls = yes tls_random_source = dev:/dev/urandom transport_maps = mysql:/etc/postfix/mysql_peraddress_transport_maps.cf, mysql:/etc/postfix/mysql_virtual_transport_maps.cf unknown_local_recipient_reject_code = 550 verp_delimiter_filter = -=+ virtual_alias_domains = mysql:/etc/postfix/mysql_virtual_alias_domains.cf virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf virtual_gid
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 3:16 PM, Noel Jones wrote: > On 1/28/2010 4:46 PM, Jeff Weinberger wrote: >> >> virtual_alias_domains = mysql:/etc/postfix/mysql_virtual_alias_domains.cf > > does lists.mylistserver.com match the above lookup? > postmap -q lists.mylistserver.com mysql:... > No. `postmap -q "lists.mylistserver.com" mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing (empty). However, `postmap -q "lists.mylistserver.com" mysql:/etc/postfix/mysql_relay_domain_maps.cf returns "OK" (a constant value, as recommended). I was hopeful that you had identified something here...so I did test to be sure.
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 3:39 PM, Noel Jones wrote: > On 1/28/2010 5:36 PM, Jeff Weinberger wrote: >> >> On Thu, Jan 28, 2010 at 3:16 PM, Noel Jones >> wrote: >>> >>> On 1/28/2010 4:46 PM, Jeff Weinberger wrote: >>>> >>>> virtual_alias_domains = >>>> mysql:/etc/postfix/mysql_virtual_alias_domains.cf >>> >>> does lists.mylistserver.com match the above lookup? >>> postmap -q lists.mylistserver.com mysql:... >>> >> >> No. `postmap -q "lists.mylistserver.com" >> mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing >> (empty). However, `postmap -q "lists.mylistserver.com" >> mysql:/etc/postfix/mysql_relay_domain_maps.cf returns "OK" (a constant >> value, as recommended). >> >> I was hopeful that you had identified something here...so I did test to be >> sure. > > So enable debug output on smtpd (or add a test client to debug_peer_list) > and show us the UNALTERED results of a failed transaction. > http://www.postfix.org/DEBUG_README.html#debug_peer > OK, I see what this will do - thanks for the suggestion. I'll post the complete log here (naturally, anything sensitive masked, but otherwise unaltered).
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 4:02 PM, Jeff Weinberger wrote: > On Thu, Jan 28, 2010 at 3:39 PM, Noel Jones wrote: >> On 1/28/2010 5:36 PM, Jeff Weinberger wrote: >>> >>> On Thu, Jan 28, 2010 at 3:16 PM, Noel Jones >>> wrote: >>>> >>>> On 1/28/2010 4:46 PM, Jeff Weinberger wrote: >>>>> >>>>> virtual_alias_domains = >>>>> mysql:/etc/postfix/mysql_virtual_alias_domains.cf >>>> >>>> does lists.mylistserver.com match the above lookup? >>>> postmap -q lists.mylistserver.com mysql:... >>>> >>> >>> No. `postmap -q "lists.mylistserver.com" >>> mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing >>> (empty). However, `postmap -q "lists.mylistserver.com" >>> mysql:/etc/postfix/mysql_relay_domain_maps.cf returns "OK" (a constant >>> value, as recommended). >>> >>> I was hopeful that you had identified something here...so I did test to be >>> sure. >> >> So enable debug output on smtpd (or add a test client to debug_peer_list) >> and show us the UNALTERED results of a failed transaction. >> http://www.postfix.org/DEBUG_README.html#debug_peer >> > > OK, I see what this will do - thanks for the suggestion. I'll post the > complete log here (naturally, anything sensitive masked, but otherwise > unaltered). > I'm closing this request. I've found some issues with MySQL on my system (no explanation other than user error for the attempts without mysql), that have now been fixed. This has caused the postfix behavior to return to normal and expected, and all is working as I want. My apologies for bringing this to this forum (though I"m sure you'll see how I thought this was a postfix issue). Thank you to all who helped find the ways to diagnose this. This has raised other questions that I do not fully understand, but for clarity will post them separately. Thank you.
%d and %s in mysql queries?
I am using mysql (quite successfully in most cases) to do lookups for a variety of reasons in postfix. Recently, I had some issues with a domain lookup and in the testing tried varying my MySQL query between using %d and %s as the lookup key. The documentation is clear on this when the query is for an address. It may be as clear, and I may not be understanding this, but I would like to ask for help understanding the difference when the lookup is for a domain. In this case, I have in main.cf: relay_domains = mysql:/etc/postfix/mysql_relay_domains.cf and the query in /etc/postfix/mysql_relay_domains.cf is: query = SELECT 'OK' FROM domain WHERE domain='%d' AND type='relay' I chose %d because I'm looking up only the domain in this case. I noticed that this worked fine when the domain in question is of the form "domain.tld" but didn't work (meaning the result returned from postmap -q... was null) when the domain is of the form "sub.domain.tld" (even though "sub.domain.tld" is in the "domain" table with type "relay"). When I changed the query to use %s, it worked in both cases. So my questions are: 1) Is this expected behavior? 2) in the case where the lookup is for a domain, what is the operative difference between using %d and %s I am hoping to gain a better understanding of these two substitutions. Recommendations on best-practices are appreciated as well, but I'd like to understand the expected behavior. If this is documented and I missed it or didn't understand it well, please point me to the documentation page.
Re: %d and %s in mysql queries?
On Sat, Jan 30, 2010 at 4:41 PM, Wietse Venema wrote: > Jeff Weinberger: >> I am using mysql (quite successfully in most cases) to do lookups for >> a variety of reasons in postfix. >> >> Recently, I had some issues with a domain lookup and in the testing >> tried varying my MySQL query between using %d and %s as the lookup >> key. >> >> The documentation is clear on this when the query is for an address. > > The %d is defined when a key or result is an address: > > %d When the input key is an address of the form u...@domain, > > %d When a result attribute value is an address of the form > u...@domain > > Therefore, %d is not defined for non-address forms. > > Wieste > Thank you! So my use of %d in the case of relay_domains lookup was just incorrect. I understand this now - thanks.
Re: Redirect all mail from one domain to the same u...@otherdomain?
Mouss wrote: Jeff Weinberger a �crit : > [snip] > > This is helpful, but I still need the query to take all the other > alias domains into account. So, I need the IF condition, or a second map. > I don't think so. I used this. I don't remember the details, but the idea is that you can often get rid of flow control (if, ...) using additional tables. Thanks - yes, additional tables, maps, etc. would make the sql coding far simpler. > Thank you for your help...it's informative as always! > > if the wildcard alias will produce the result I need then this is > resolved. > @example.org @example.com works, but smtpd will accept mail to anyth...@... (virtual_alias_maps are used for recipient validation during the smtp transaction). if all addresses are valid (catchall or whatver), this is ok. otherwise, it's bad. in any case, you must make sure that mail isn't bounced after it is accepted (queued). This is what happens by default (after virtual alias expansion, a delivery error occurs, and an NDR is generated). Thank you - this will work well. I'll use a catchall mailbox to make sure that I don't generate an NDR. thanks for your help!