Re: header_checks in master.cf?
On 4/4/2011 9:54 PM, email builder wrote: OK, sorry again. I had assumed because you can turn off header checking by using receive_override_options, you could also override (change) them. It is possible to override header_checks by defining a different cleanup_service_name for smtpd, then defining that cleanup service with a header_checks override. This can get pretty messy, you can find examples in the list archives. The better solution is to use multiple instances. All postfix versions support multiple instances. Newer versions include tools to make multiple instance creation/maintenance easier. Reading smtpd(8) manpage, it does seem like smtpd_data_restrictions would be a good place to be able to inspect the mail headers and use the PREPEND to insert a new header. But I was using check_client_access to do so, and that only seems to inspect the client address and related information but looking through the list of restrictions I cannot understand which one allows the inspection of the message data itself. The postfix smtpd_*_restrictions allow you to inspect envelope information. To inspect message header or body contents, postfix provides header_checks, body_checks, and an interface for an external content filter, proxy, or milter. http://www.postfix.org/CONTENT_INSPECTION_README.html and before you try it and complain about it not working -- No, you cannot use body_checks to PREPEND a new header.
Re: header_checks in master.cf?
Noel Jones: [ Charset ISO-8859-1 unsupported, converting... ] On 4/4/2011 9:54 PM, email builder wrote: OK, sorry again. I had assumed because you can turn off header checking by using receive_override_options, you could also override (change) them. It is possible to override header_checks by defining a different cleanup_service_name for smtpd, then defining that cleanup service with a header_checks override. This can get pretty messy, you can find examples in the list archives. The better solution is to use multiple instances. All postfix versions support multiple instances. Newer versions include tools to make multiple instance creation/maintenance easier. He seems to want sender IP address selection based on some message attribute. We discussed that early 2010 in http://www.irbs.net/internet/postfix/1001/0390.html I solved this specific problem a few days later with Postfix 2.7 by changing the effect of FILTER transport: (i.e. transport without next-hop destination). The OP appears to be stuck on Postfix 2.3 so he will have to use the solution that involves specifying FILTER smtp:nexthop where each nexthop is a separate Postfix instance with its own myhostname and inet_interfaces setting. In the 2010 discussion I forgot to mention that he'd also have to change the inet_interfaces setting of the primary Postfix instance to avoid mail loops back to myself errors. To fix this, specify inet_interfaces = 127.0.0.1 1.2.3.4 where 1.2.3.4 is the primary IP address. This way, the primary instance won't try to receive mail for the additional instances. Wietse
Re: header_checks in master.cf?
On Mon, Apr 04, 2011 at 06:33:20PM -0700, email builder wrote: I am testing a simple header_check that uses PREPEND to add a custom header to messages. Uh, no, I think it is not simple at all. Is this the same issue you're working on? You have spent much time, and gotten much help, none of which is actually getting you closer to the ultimate goal (whatever it may be, you really did not say.) Thank you for your strong encouragement, but actually, the issue is exactly as I've stated. It does happen to be tangentially related to my other issue, but I had set that aside for the time being and for now, I just wanted to go ahead and add a custom header to outgoing messages, nothing more. I am aware of Simon Mudd's good work, and appreciate your encouragement to go that route. I as we're a bit stuck on my other issue, I'll review this and maybe change our policy. Thanks again. At some point you should ask: is it more difficult to keep on this path, or to buck the OS packaging system and *upgrade* to a recent Postfix version which probably CAN do what you want. Since you mentioned 2.3.3 somewhere, I suppose that means RHEL or CentOS. Fortunately it is very easy to use a SRPM and rpmbuild(1). Simon Mudd maintains recent Postfix SRPMs. Go for 2.8.2 if he has posted that one already. Disable any automated upgrades. Those have no place on any kind of server anyway. Why the fear of leaving the OS package? What am I missing? As I mentioned last night in the other thread, OVERVIEW.html has Postfix's big picture, which might prevent you from wasting time working on things which are not possible. If you're going to stay with the ancient version, use its copy of the documentation, so as to avoid the This feature is available in Postfix 2.4 and later gotchas. As Jeroen mentioned in the second thread, you will do better here with complete problem and goal descriptions. All we know are the wacky, unworkable hacks you are trying to do. We don't know what you're really wanting to accomplish. I suspect you need one of these three: 1. A more recent Postfix 2. A different MTA altogether 3. A more reasonable goal
Re: header_checks in master.cf?
On 4/4/2011 9:54 PM, email builder wrote: OK, sorry again. I had assumed because you can turn off header checking by using receive_override_options, you could also override (change) them. It is possible to override header_checks by defining a different cleanup_service_name for smtpd, then defining that cleanup service with a header_checks override. This can get pretty messy, you can find examples in the list archives. Mmm, thanks. I just happened to find this idea late yesterday when researching this issue. It's interesting, but it looks like it ultimately isn't necessary. The better solution is to use multiple instances. All postfix versions support multiple instances. Newer versions include tools to make multiple instance creation/maintenance easier. I've been trying to avoid this, but we might end up having to go this route. Thanks for the encouragement. Reading smtpd(8) manpage, it does seem like smtpd_data_restrictions would be a good place to be able to inspect the mail headers and use the PREPEND to insert a new header. But I was using check_client_access to do so, and that only seems to inspect the client address and related information but looking through the list of restrictions I cannot understand which one allows the inspection of the message data itself. The postfix smtpd_*_restrictions allow you to inspect envelope information. To inspect message header or body contents, postfix provides header_checks, body_checks, and an interface for an external content filter, proxy, or milter. http://www.postfix.org/CONTENT_INSPECTION_README.html This jives with what I'd understood from the documentation - smtp_*_restrictions let you check the envelope only, not the headers/body. But I was confused by some people giving examples of how to add headers with PREPEND actions during some smtpd_*_restrictions checks. It turns out (from my testing, but I can't find this in the docs) that you can still use PREPEND to add a header even though you're looking at certain envelope data. The other confusing bit was what to test for -- since you're looking at the envelope, you can't just look for /^From:/ for example. It's not there. But since I'm trying to unconditionally add a header, the trick seems to be that what's there does not matter (just use /^/), and in that sense, the envelope check for, say, sender, is perfect - it's just one line (so your header doesn't get added more than once). So all you have to do is: master.cf smtpd process entry: -o smtpd_data_restrictions=check_sender_access,pcre:/etc/postfix/add_my_header /etc/postfix/add_my_header: /^/ PREPEND X-My-Header: Hello_world Easier than I thought. Now, PLEASE don't take this the wrong way, but I'm wondering why no one offered this solution. Am I doing something I should not be doing?
Re: header_checks in master.cf?
On 4/5/2011 12:54 PM, email builder wrote: master.cf smtpd process entry: -o smtpd_data_restrictions=check_sender_access,pcre:/etc/postfix/add_my_header /etc/postfix/add_my_header: /^/ PREPEND X-My-Header: Hello_world Easier than I thought. Now, PLEASE don't take this the wrong way, but I'm wondering why no one offered this solution. Am I doing something I should not be doing? Nothing wrong with the above setting if it solves your original problem. I expect no one offered that as a solution because you have yet to explain what problem you're trying to solve in a way everyone understands. Good luck. -- Noel Jones
Re: header_checks in master.cf?
email builder: some smtpd_*_restrictions checks. It turns out (from my testing, but I can't find this in the docs) that you can still use PREPEND to add a header even though you're looking at certain envelope data. ACCESS(5)ACCESS(5) NAME access - Postfix SMTP server access table ... PREPEND headername: headervalue Prepend the specified message header to the message. When more than one PREPEND action executes, the first prepended header appears before the second etc. prepended header. Note: this action must execute before the message content is received;itcannotexecuteinthe context of smtpd_end_of_data_restrictions. This feature is available in Postfix 2.1 and later.
Re: header_checks in master.cf?
OK, sorry again. I had assumed because you can turn off header checking by using receive_override_options, you could also override (change) them. It is possible to override header_checks by defining a different cleanup_service_name for smtpd, then defining that cleanup service with a header_checks override. This can get pretty messy, you can find examples in the list archives. The better solution is to use multiple instances. All postfix versions support multiple instances. Newer versions include tools to make multiple instance creation/maintenance easier. He seems to want sender IP address selection based on some message attribute. We discussed that early 2010 in http://www.irbs.net/internet/postfix/1001/0390.html I solved this specific problem a few days later with Postfix 2.7 by changing the effect of FILTER transport: (i.e. transport without next-hop destination). The OP appears to be stuck on Postfix 2.3 so he will have to use the solution that involves specifying FILTER smtp:nexthop where each nexthop is a separate Postfix instance with its own myhostname and inet_interfaces setting. Well, I started a new thread because I actually have a separate requirement to add a custom header. That said, I *am* trying to address the issue you so eloquently explain as well. What I ran into while solving the add-a-header issue (see my last post on this thread) was that I can use a FILTER action from a smtpd_*_restriction check to select a specialized smtp process that is bound to a given IP address. I found, however, that the FILTER action's nexthop field could not be left blank (without a colon, the action is ignored; with a colon but nothing after it, I got name service errors in my mail log). The hack to resolve that seemed to be to change the restriction check to be check_client_access so I could get at the recipient email address and parse off its domain to hand to the FILTER nexthop field. But I'm not sure what the implications of this are. Am I assuming that the MX for any recipient address is hosted at the same domain? Or does postfix still do the needed lookups for me? Testing this, it does seem to work OK, but are there other issues that this raises? Here is what I have. Apologies if this is a Bad Idea. master.cf: smtp2 unix - - n - - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 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= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_client_access,pcre:/etc/postfix/send_to_smtp2 -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/ FILTER smtp2:$1 In the 2010 discussion I forgot to mention that he'd also have to change the inet_interfaces setting of the primary Postfix instance to avoid mail loops back to myself errors. To fix this, specify inet_interfaces = 127.0.0.1 1.2.3.4 where 1.2.3.4 is the primary IP address. This way, the primary instance won't try to receive mail for the additional instances. Thanks for the detailed information about how to try solving this with a secondary postifx instance. If my solution above really is a Bad Idea, I think short of upgrading, this is where we are headed. The information you've provided is highly appreciated.
Re: header_checks in master.cf?
master.cf smtpd process entry: -o smtpd_data_restrictions=check_sender_access,pcre:/etc/postfix/add_my_header /etc/postfix/add_my_header: /^/ PREPEND X-My-Header: Hello_world Easier than I thought. Now, PLEASE don't take this the wrong way, but I'm wondering why no one offered this solution. Am I doing something I should not be doing? Nothing wrong with the above setting if it solves your original problem. OK, thanks. I expect no one offered that as a solution because you have yet to explain what problem you're trying to solve in a way everyone understands. Sorry, I'm not sure how else to say I'm just trying to add an unconditional header to outgoing messages. But due to the similarity of problem sets, I can see how this is easily confused with the other things I've been asking about. Sorry for the mess. Good luck. Thank you and thank everyone for the excellent help.
Re: header_checks in master.cf?
email builder:
What I ran into while solving the add-a-header issue (see my last
post on this thread) was that I can use a FILTER action from a
smtpd_*_restriction check to select a specialized smtp process
that is bound to a given IP address.
I found, however, that the FILTER action's nexthop field could
not be left blank (without a colon, the action is ignored;
This is incorrect. If the ':' is not present in the FILTER argument,
all Postfix versions before 2.7 will use a nexthop of $myhostname:
This code appears in Postfix 2.6, 2.5, 2.4, 2.3 and earlier, file
qmgr_message.c. Here, message-filter_xport is the FILTER argument
(transport, transport: or transport:destination):
else if (message-filter_xport
(message-tflags DEL_REQ_TRACE_ONLY_MASK) == 0) {
reply.flags = 0;
vstring_strcpy(reply.transport, message-filter_xport);
if ((nexthop = split_at(STR(reply.transport), ':')) == 0
|| *nexthop == 0)
nexthop = var_myhostname;
vstring_strcpy(reply.nexthop, nexthop);
vstring_strcpy(reply.recipient, recipient-address);
with a colon but nothing after it, I got name service errors in
my mail log).
This is incorrect. FILTER actions without : have the same effect
as FILTER actions with : followed by an empty destination.
- In both cases, all Postfix before version 2.7 will use a destination
of $myhostname.
- In both cases, Postfix 2.7 and later will use the recipient's
domain instead. That is the change that I made in January 2010.
The hack to resolve that seemed to be to change the restriction
check to be check_client_access so I could get at the recipient
email address and parse off its domain to hand to the FILTER
nexthop field.
This is incorrect. If you use the FILTER action in smtpd_*_restrictions
then that action has the same effect no matter if you use in client
restrictions, helo restrictions, and so on. Provided of course that
the information you need is available.
The following is an example where information that you need is not
available.
-o smtpd_data_restrictions=check_client_access,pcre:/etc/postfix/send_to_smtp2
/etc/postfix/send_to_smtp2:
/@(.+)/ FILTER smtp2:$1
That is incorrect. As documented, check_client_access uses the
CLIENT IP ADDRESS, not the sender or recipient EMAIL ADDRESS.
http://www.postfix.org/postconf.5.html#check_client_access
Wietse
Re: header_checks in master.cf?
What I ran into while solving the add-a-header issue (see my last
post on this thread) was that I can use a FILTER action from a
smtpd_*_restriction check to select a specialized smtp process
that is bound to a given IP address.
I found, however, that the FILTER action's nexthop field could
not be left blank (without a colon, the action is ignored;
This is incorrect. If the ':' is not present in the FILTER argument,
all Postfix versions before 2.7 will use a nexthop of $myhostname:
This code appears in Postfix 2.6, 2.5, 2.4, 2.3 and earlier, file
qmgr_message.c. Here, message-filter_xport is the FILTER argument
(transport, transport: or transport:destination):
else if (message-filter_xport
(message-tflags DEL_REQ_TRACE_ONLY_MASK) == 0) {
reply.flags = 0;
vstring_strcpy(reply.transport, message-filter_xport);
if ((nexthop = split_at(STR(reply.transport), ':')) == 0
|| *nexthop == 0)
nexthop = var_myhostname;
vstring_strcpy(reply.nexthop, nexthop);
vstring_strcpy(reply.recipient, recipient-address);
with a colon but nothing after it, I got name service errors in
my mail log).
This is incorrect. FILTER actions without : have the same effect
as FILTER actions with : followed by an empty destination.
- In both cases, all Postfix before version 2.7 will use a destination
of $myhostname.
Hmm, well I just tested it again, and the behavior I'm seeing is as I explained
(smtp2 (no colon) results in *normal* delivery (not delivered via the smtp2
process at all); smtp2: gives errors and creates a bounce).
Either way (yours or mine), this is not desirable behavior, so I'll just write
the difference off to whatever hacks RedHat has done to their version 2.3.3.
- In both cases, Postfix 2.7 and later will use the recipient's
domain instead. That is the change that I made in January 2010.
I look forward to being able to make use of that code in the future. I
appreciate your work and am sorry I haven't been able to simply upgrade to take
advantage of this. BTW, if you made exactly that change (that makes FILTER
work
in the scenario I've explained), what is the advantage of using the
sender_dependent_relayhost_maps or sender_dependent_transport_maps stuff over
doing what I've explained above?
The hack to resolve that seemed to be to change the restriction
check to be check_client_access so I could get at the recipient
email address and parse off its domain to hand to the FILTER
nexthop field.
This is incorrect. If you use the FILTER action in smtpd_*_restrictions
then that action has the same effect no matter if you use in client
restrictions, helo restrictions, and so on. Provided of course that
the information you need is available.
Well, first, there is a typo in what I wrote. I meant to write that I needed
to
change it to use check_recipient_access
I'm not saying that FILTER is different. All I'm saying is that I needed to
use
check_RECIPIENT_access and not check_CLIENT_access so that I could parse out
the
recipient's domain.
The following is an example where information that you need is not
available.
-o
smtpd_data_restrictions=check_client_access,pcre:/etc/postfix/send_to_smtp2
/etc/postfix/send_to_smtp2:
/@(.+)/ FILTER smtp2:$1
That is incorrect. As documented, check_client_access uses the
CLIENT IP ADDRESS, not the sender or recipient EMAIL ADDRESS.
http://www.postfix.org/postconf.5.html#check_client_access
Right. Sorry - it was a typo. Using check_client_access was fine for adding a
custom header to messages, but what you've explained is exactly why I changed
it
to check_recipient_access in order to FILTER out to a custom smtp process.
Again, I'm *really sorry* for the goof.
Here is what I've done with the typo corrected. Is this a Bad Idea? Are there
problems with naively using the domain from the recipient email address as the
nexthop value?
master.cf:
smtp2 unix - - n - - smtp
-o smtp_bind_address=bbb.bbb.bbb.bbb
127.0.0.1:10024 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=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o
smtpd_data_restrictions=check_recipient_access,pcre:/etc/postfix/send_to_smtp2
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o mynetworks=127.0.0.0/8
/etc/postfix/send_to_smtp2:
/@(.+)/ FILTER smtp2:$1
Re: header_checks in master.cf?
email builder: Here is what I've done with the typo corrected. Is this a Bad Idea? Are there problems with naively using the domain from the recipient email address as the nexthop value? master.cf: smtp2 unix - - n - - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 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= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_recipient_access,pcre:/etc/postfix/send_to_smtp2 -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/ FILTER smtp2:$1 This sends all mail to transport smtp2. If that is what you want, then you can get a better result with default_transport = smtp2, You can get a simpler result by adding -o smtp_bind_address... to the default smtp delivery transport. Wietse
Re: header_checks in master.cf?
Here is what I've done with the typo corrected. Is this a Bad Idea? Are there problems with naively using the domain from the recipient email address as the nexthop value? master.cf: smtp2 unix - - n- - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 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= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_recipient_access,pcre:/etc/postfix/send_to_smtp2 -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/ FILTER smtp2:$1 This sends all mail to transport smtp2. If that is what you want, then you can get a better result with default_transport = smtp2, You can get a simpler result by adding -o smtp_bind_address... to the default smtp delivery transport. Sorry, the smtpd listener on port 10024 only gets *some* of the mail on the server. There is another smtpd listener on a different port that I didn't show that does not use the smtp2 process to send mail. Thus, only the mail that I route into the smtpd listener on port 10024 is sent via the IP address bbb.bbb.bbb.bbb. So it does seem possible (and reasonably simple) to achieve this feature, but I'm still keen to know if there are any Bad Ideas lurking with this scheme.
Re: header_checks in master.cf?
email builder: Here is what I've done with the typo corrected. Is this a Bad Idea? Are there problems with naively using the domain from the recipient email address as the nexthop value? master.cf: smtp2 unix - - n- - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 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= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_recipient_access,pcre:/etc/postfix/send_to_smtp2 -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/ FILTER smtp2:$1 This sends all mail to transport smtp2. If that is what you want, then you can get a better result with default_transport = smtp2, You can get a simpler result by adding -o smtp_bind_address... to the default smtp delivery transport. Sorry, the smtpd listener on port 10024 only gets *some* of the mail on the server. There is another smtpd listener on a different port that I didn't show that does not use the smtp2 process to send mail. Thus, only the mail that I route into the smtpd listener on port 10024 is sent via the IP address bbb.bbb.bbb.bbb. So it does seem possible (and reasonably simple) to achieve this feature, but I'm still keen to know if there are any Bad Ideas lurking with this scheme. The configuration makes absolutely no sense at all. I also have enough of this game where you reveal a tiny piece of the puzzle at a time. Good luck. Wietse
Re: header_checks in master.cf?
On 4/5/2011 3:35 PM, email builder wrote: Here is what I've done with the typo corrected. Is this a Bad Idea? Are there problems with naively using the domain from the recipient email address as the nexthop value? master.cf: smtp2 unix - - n- - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 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= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_recipient_access,pcre:/etc/postfix/send_to_smtp2 -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/ FILTER smtp2:$1 This sends all mail to transport smtp2. If that is what you want, then you can get a better result with default_transport = smtp2, You can get a simpler result by adding -o smtp_bind_address... to the default smtp delivery transport. Sorry, the smtpd listener on port 10024 only gets *some* of the mail on the server. There is another smtpd listener on a different port that I didn't show that does not use the smtp2 process to send mail. Thus, only the mail that I route into the smtpd listener on port 10024 is sent via the IP address bbb.bbb.bbb.bbb. So it does seem possible (and reasonably simple) to achieve this feature, but I'm still keen to know if there are any Bad Ideas lurking with this scheme. Some problems lurking in the shadows ... Routing mail with smtpd_recipient_restrictions and FILTER will give inconsistent results with multi-recipient mail. The FILTER action is a per-message setting -- the last recipient domain sent will be the one filtered on. Using a transport table and multiple postfix instances is the only reliable solution. In smtpd_data_restrictions, multiple recipients are undefined. If the message contains multiple recipients, no recipients information will be available in smtpd_data_restrictions. -- Noel Jones
Re: header_checks in master.cf?
Here is what I've done with the typo corrected. Is this a Bad Idea? Are there problems with naively using the domain from the recipient email address as the nexthop value? master.cf: smtp2 unix - - n - - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 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= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_recipient_access,pcre:/etc/postfix/send_to_smtp2 -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/ FILTER smtp2:$1 This sends all mail to transport smtp2. If that is what you want, then you can get a better result with default_transport = smtp2, You can get a simpler result by adding -o smtp_bind_address... to the default smtp delivery transport. Sorry, the smtpd listener on port 10024 only gets *some* of the mail on the server. There is another smtpd listener on a different port that I didn't show that does not use the smtp2 process to send mail. Thus, only the mail that I route into the smtpd listener on port 10024 is sent via the IP address bbb.bbb.bbb.bbb. So it does seem possible (and reasonably simple) to achieve this feature, but I'm still keen to know if there are any Bad Ideas lurking with this scheme. The configuration makes absolutely no sense at all. Hmm, I'm not sure why you see *no* sense in it. If there are two smtpd listeners (that take mail from a content filter) on different ports, and the one I've shown uses this scheme to send via smtp2 which is bound to another IP address (the one I didn't show just lets mail go via normal means, i.e. the default smtp process), isn't there some logic there? I already have the mail I want to send on a different IP address/network interface segregated by the time it gets to the content filter, so this scheme seems to do what I need. I also have enough of this game where you reveal a tiny piece of the puzzle at a time. My sincerest apologies. Wietse, the last thing I'd like to do is frustrate you (or any others who've been so kind to indulge me here). I was merely trying to reduce confusion by eliminating the parts of master.cf that are not related to what I'm trying to do. Say for the sake of clarity, I have two groups of users. I wish to keep mail sent by each group separate (sent on different network interfaces). If I have a webmail system that submits messages to postfix on a designated port number for each of these groups, then the separation is already achieved by the time Postfix sees the messages, so all I am trying to do is ensure Postfix can then route mail from one of those groups out of a different IP address. I showed the configuration for that portion of this scheme which begins when mail comes back from content filtering. All is well before this step, which is why I didn't believe it is relevant. If that's still clear as mud, I apologize again and I guess I'll live with what I've shown above, as it seems to be working fine so far, segregating my outgoing mail perfectly. Thanks for all you do and for the AWESOME software.
Re: header_checks in master.cf?
email builder: The configuration makes absolutely no sense at all. Hmm, I'm not sure why you see *no* sense in it. If you can configure Postfix to send some email to port 10024 (which uses a wild-card access map rule to send out all email via transport smtp2) Then you can configure Postfix to send out that same email via transport smtp2 and avoid a ton of complexity. I also have enough of this game where you reveal a tiny piece of the puzzle at a time. My sincerest apologies. Wietse, the last thing I'd like to do is frustrate you (or any others who've been so kind to indulge me here). I was merely trying to reduce confusion by eliminating the parts of master.cf that are not related to what I'm trying to do. I propose a solution, then you reveal a little more of your plans, to explain why my solution is not valid. You have wasted enough of my precious time. Goodbye. Wietse
Re: header_checks in master.cf?
Here is what I've done with the typo corrected. Is this a Bad Idea? Are there problems with naively using the domain from the recipient email address as the nexthop value? master.cf: smtp2 unix - - n - - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 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= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_recipient_access,pcre:/etc/postfix/send_to_smtp2 -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/FILTER smtp2:$1 This sends all mail to transport smtp2. If that is what you want, then you can get a better result with default_transport = smtp2, You can get a simpler result by adding -o smtp_bind_address... to the default smtp delivery transport. Sorry, the smtpd listener on port 10024 only gets *some* of the mail on the server. There is another smtpd listener on a different port that I didn't show that does not use the smtp2 process to send mail. Thus, only the mail that I route into the smtpd listener on port 10024 is sent via the IP address bbb.bbb.bbb.bbb. So it does seem possible (and reasonably simple) to achieve this feature, but I'm still keen to know if there are any Bad Ideas lurking with this scheme. Some problems lurking in the shadows ... Routing mail with smtpd_recipient_restrictions and FILTER will give inconsistent results with multi-recipient mail. The FILTER action is a per-message setting -- the last recipient domain sent will be the one filtered on. Using a transport table and multiple postfix instances is the only reliable solution. In smtpd_data_restrictions, multiple recipients are undefined. If the message contains multiple recipients, no recipients information will be available in smtpd_data_restrictions. Ah ha! Indeed, testing multiple recipients, it seems to quietly fall back to the default smtp process for sending, which is exactly the behavior I was seeing when the FILTER was specified without the colon (Wietse noted that it *should* have been trying to send via $myhostname, but in my version, for whatever reason, I'm seeing different behavior). While there are some minor unexplained bits, this makes enough sense. So this scheme isn't going to work 100%. Looks like it WOULD work with two minor changes: 1) start a separate instance which is fairly dumb/basic, just ready to send mail normally that it gets from this FILTER action 2) change the FILTER action to this: /^/FILTER smtp2:second.postfix.instance.example.com However, you noted that when you have multiple recipients, smtpd_data_restrictions won't have any recipient data. Does that mean even /^/ will not match? If I change smtp_data_restrictions to use check_client_access instead, can I rely on it to *ALWAYS* have at least *something* there (doesn't matter what, since I'm matching on /^/)? If not, should I try something like check_client_mx_access? Thank you!
Re: header_checks in master.cf?
The configuration makes absolutely no sense at all. Hmm, I'm not sure why you see *no* sense in it. If you can configure Postfix to send some email to port 10024 (which uses a wild-card access map rule to send out all email via transport smtp2) Then you can configure Postfix to send out that same email via transport smtp2 and avoid a ton of complexity. Yes, I'd love to do that. But maybe I'm missing something fundamental or thinking too hard. As I see it, you have to have a smtpd listener accepting mail from the content filter, and the complex part is that, as you mentioned, smtpd processes do not choose the smtp process (there's more than one on purpose). As I've said all along, there are two groupings of mail, and only one group goes through this particular smtpd listener (and thus smtp2) that I've been showing. If anyone can explain in a little more detail what Wietse is suggesting above, I'd LOVE to hear what you have to say. But I suspect he is assuming there is no other smtpd listener coming out of the content filter (which there is). I also have enough of this game where you reveal a tiny piece of the puzzle at a time. My sincerest apologies. Wietse, the last thing I'd like to do is frustrate you (or any others who've been so kind to indulge me here). I was merely trying to reduce confusion by eliminating the parts of master.cf that are not related to what I'm trying to do. I propose a solution, then you reveal a little more of your plans, to explain why my solution is not valid. You have wasted enough of my precious time. Goodbye. Sorry my attempt to make things easier has backfired in your view. Again, sincerest apologies.
Re: header_checks in master.cf?
Here is what I've done with the typo corrected. Is this a Bad Idea? Are there problems with naively using the domain from the recipient email address as the nexthop value? master.cf: smtp2 unix - - n - - smtp -o smtp_bind_address=bbb.bbb.bbb.bbb 127.0.0.1:10024 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= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=check_recipient_access,pcre:/etc/postfix/send_to_smtp2 -osmtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 /etc/postfix/send_to_smtp2: /@(.+)/ FILTER smtp2:$1 This sends all mail to transport smtp2. If that is what you want, then you can get a better result with default_transport = smtp2, You can get a simpler result by adding -o smtp_bind_address... to the default smtp delivery transport. Sorry, the smtpd listener on port 10024 only gets *some* of the mail on the server. There is another smtpd listener on a different port that I didn't show that does not use the smtp2 process to send mail. Thus, only the mail that I route into the smtpd listener on port 10024 is sent via the IP address bbb.bbb.bbb.bbb. So it does seem possible (and reasonably simple) to achieve this feature, but I'm still keen to know if there are any Bad Ideas lurking with this scheme. Some problems lurking in the shadows ... Routing mail with smtpd_recipient_restrictions and FILTER will give inconsistent results with multi-recipient mail.The FILTER action is a per-message setting -- the last recipient domain sent will be the one filtered on. Using a transport table and multiple postfix instances is the only reliable solution. In smtpd_data_restrictions, multiple recipients are undefined. If the message contains multiple recipients, no recipients information will be available in smtpd_data_restrictions. Ah ha! Indeed, testing multiple recipients, it seems to quietly fall back to the default smtp process for sending, which is exactly the behavior I was seeing when the FILTER was specified without the colon (Wietse noted that it *should* have been trying to send via $myhostname, but in my version, for whatever reason, I'm seeing different behavior). While there are some minor unexplained bits, this makes enough sense. So this scheme isn't going to work 100%. Looks like it WOULD work with two minor changes: 1) start a separate instance which is fairly dumb/basic, just ready to send mail normally that it gets from this FILTER action 2) change the FILTER action to this: /^/FILTER smtp2:second.postfix.instance.example.com I've just finished implementing this and it's working nicely. Hopefully I've pleased everyone who kept telling me to use multiple instances. :-) This seems to be the only way to do this, at least if I stay with version 2.3.3. However, you noted that when you have multiple recipients, smtpd_data_restrictions won't have any recipient data. Does that mean even /^/ will not match? If I change smtp_data_restrictions to use check_client_access instead, can I rely on it to *ALWAYS* have at least *something* there (doesn't matter what, since I'm matching on /^/)? If not, should I try something like check_client_mx_access? This was in fact still an issue - when sending to multiple recipients, the regular expression failed to match anything since there's nothing there apparently, so I changed it to check for check_client_access and so far, that seems to always have something in it, so the regular expression matches and the mail goes where it should. Now just have to spend some time with the second instance to trim it down and make sure it's not doing stuff it doesn't need to, etc. (any hints on where to find minimalist process list for master.cf for instances that ONLY accept from another process on localhost and send mail out? Is the default master.cf about as trimmed down as I can go?). Thanks again.
Re: header_checks in master.cf?
I am testing a simple header_check that uses PREPEND to add a custom header to messages. 1) I *always* want to add the header, so the detected header in the rule doesn't matter so much. Does anyone have advice for the best header to detect so I won't miss any messages? Is /^From:/ the best? Or maybe /^Date:/ ? Anyhow, my PREPEND is working fine as a header_check in main.cf, but when I put it in master.cf in a smtpd listener that picks up mail from my content filter, it seems to be ignored completely. According to header_checks(5) this is implemented by the cleanup server. header/body_checks are documented as parameters on the cleanup(8) manpage. They are not documented as parameters on the smtpd(8) manpage. All this confirms that header/body_checks are a cleanup(8) feature, not an smtpd(8) feature, Meaning, it's pointless to specify this on the smtpd(8) command line. OK, sorry again. I had assumed because you can turn off header checking by using receive_override_options, you could also override (change) them. Reading smtpd(8) manpage, it does seem like smtpd_data_restrictions would be a good place to be able to inspect the mail headers and use the PREPEND to insert a new header. But I was using check_client_access to do so, and that only seems to inspect the client address and related information but looking through the list of restrictions I cannot understand which one allows the inspection of the message data itself.
Re: header_checks in master.cf?
On Mon, Apr 04, 2011 at 06:33:20PM -0700, email builder wrote: I am testing a simple header_check that uses PREPEND to add a custom header to messages. Uh, no, I think it is not simple at all. Is this the same issue you're working on? You have spent much time, and gotten much help, none of which is actually getting you closer to the ultimate goal (whatever it may be, you really did not say.) At some point you should ask: is it more difficult to keep on this path, or to buck the OS packaging system and *upgrade* to a recent Postfix version which probably CAN do what you want. Since you mentioned 2.3.3 somewhere, I suppose that means RHEL or CentOS. Fortunately it is very easy to use a SRPM and rpmbuild(1). Simon Mudd maintains recent Postfix SRPMs. Go for 2.8.2 if he has posted that one already. Disable any automated upgrades. Those have no place on any kind of server anyway. Why the fear of leaving the OS package? What am I missing? As I mentioned last night in the other thread, OVERVIEW.html has Postfix's big picture, which might prevent you from wasting time working on things which are not possible. If you're going to stay with the ancient version, use its copy of the documentation, so as to avoid the This feature is available in Postfix 2.4 and later gotchas. As Jeroen mentioned in the second thread, you will do better here with complete problem and goal descriptions. All we know are the wacky, unworkable hacks you are trying to do. We don't know what you're really wanting to accomplish. I suspect you need one of these three: 1. A more recent Postfix 2. A different MTA altogether 3. A more reasonable goal -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
