Re: PATCH: Possible reasons for qmgr loading the system?
To apply this patch, cd into the Postfix-2.5.* top-level source directory and execute: $ patch thismessage We were able to reproduce the scheduler looping problem, and it does not recur with the patched version A question ... what' the way to make this patch to be included in Ubuntu Server postfix packages? I mean, should I submit your message+patch to the package maintainers of Ubuntu / Debian / Redhat so that new postfix packages with the bug corrected are released as updates for users? Or ... you just publish the patch / bug somewhere and then the package maintainers update their sources automatically without we or you needing to contact them? :? I can patch postfix's sources, but then I loose Ubuntu package security updates and will force me to maintain postfix from sources since this moment. The best way would be your patch to be integrated in postfix and new security postfix packages to be released by package maintainers, but I don't know how to force that. Thanks. -- Santiago Romero
smtpd_sender_login_maps subdomains
Hello, i do some tests with smtpd_sender_login_maps which is already working. One question: is it right that subdomains which should be able to send mails also need to be declared in my mapfile? My tests with wildcards did not succeed. Thanks, Andre
Re: PATCH: Possible reasons for qmgr loading the system?
On Fri, 06 Mar 2009 10:07:26 +0100 Santiago Romero srom...@servicom2000.com wrote: A question ... what' the way to make this patch to be included in Ubuntu Server postfix packages? I mean, should I submit your message+patch to the package maintainers of Ubuntu / Debian / Redhat so that new postfix packages with the bug corrected are released as updates for users? Or ... you just publish the patch / bug somewhere and then the package maintainers update their sources automatically without we or you needing to contact them? :? I can patch postfix's sources, but then I loose Ubuntu package security updates and will force me to maintain postfix from sources since this moment. The best way would be your patch to be integrated in postfix and new security postfix packages to be released by package maintainers, but I don't know how to force that. In a perfect world, the program maintainers would know about the patch and take steps to correct their package/port or whatever. You might want to contact the maintainer of Postfix for your Distro and see if they are planning on updating the package/port. Usually, they do get a little annoyed if you start bugging them 5 seconds after the patch is released. Some of them actually have day jobs. -- Gerard postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Cheese -- milk's leap toward immortality. Clifton Fadiman, Any Number Can Play signature.asc Description: PGP signature
Re: PATCH: Possible reasons for qmgr loading the system?
Gerard escribió: In a perfect world, the program maintainers would know about the patch and take steps to correct their package/port or whatever. You might want to contact the maintainer of Postfix for your Distro and see if they are planning on updating the package/port. Usually, they do get a little annoyed if you start bugging them 5 seconds after the patch is released. Some of them actually have day jobs Well, I'm not planning to bug them with the patch. I don't know if the integration of the patch with the current package versions is automatic or author / bug discoverers must or should notify them to package maintainers... That's what I was asking: if the process is automatic or should I notify / help in any way. -- Santiago Romero
Re: PATCH: Possible reasons for qmgr loading the system?
Santiago Romero: To apply this patch, cd into the Postfix-2.5.* top-level source directory and execute: $ patch thismessage We were able to reproduce the scheduler looping problem, and it does not recur with the patched version A question ... what' the way to make this patch to be included in Ubuntu Server postfix packages? I will release this as part of Postfix 2.5.7. Meanwhile, you can use oqmgr and it it will an all likelihood perform just as well. I mean, should I submit your message+patch to the package maintainers of Ubuntu / Debian / Redhat so that new postfix packages with the bug corrected are released as updates for users? Or ... you just publish the patch / bug somewhere and then the package maintainers update their sources automatically without we or you needing to contact them? :? I can patch postfix's sources, but then I loose Ubuntu package security updates and will force me to maintain postfix from sources since this moment. The best way would be your patch to be integrated in postfix and new security postfix packages to be released by package maintainers, but I don't know how to force that. I have no control over vendors and distributors. Wietse
Re: Local mail listener
Daniel L. Miller: Wietse Venema wrote: Daniel L. Miller: On a whim, I tried something else. I tried telnet'ing to the two listeners - but used the EHLO command to see what was reported. I do get different responses. Does this mean anything significant? I notice The only thing that matters is that the proxy replies with 2xx to the DATA command, which is not allowed by the SMTP protocol. But (supposedly) that reply should not be getting generated by ASSP - but is being passed on from Postfix. Or is that totally wrong - and I need to focus on a possible ASSP bug? For a proper analysis, you need to make accurate recordings: 1) One tcpdump for client-before-proxy postfix smtpd 2) One tcpdump for before-proxy postfix smtpd-proxy 3) One tcpdump for proxy-after-proxy postfix smtpd Then we have the evidence to decide which program responds out of protocol. I will not participate in this discussion until you have proper evidence. Wietse
Re: Local mail listener
On Fri, Mar 6, 2009 at 8:52 AM, Wietse Venema wie...@porcupine.org wrote: 1) One tcpdump for client-before-proxy postfix smtpd 2) One tcpdump for before-proxy postfix smtpd-proxy 3) One tcpdump for proxy-after-proxy postfix smtpd Then we have the evidence to decide which program responds out of protocol. I will not participate in this discussion until you have proper evidence. Wietse Daniel, you can use: 1) tcpdump -nn -i ethX -s 0 -A port 25 # (maybe -i lo) 2) tcpdump -nn -i lo -s 0 -A port 225 3) tcpdump -nn -i lo -s 0 -A port 325 -- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net
Re: smtpd_sender_login_maps subdomains
Andre H?bner: Hello, i do some tests with smtpd_sender_login_maps which is already working. One question: is it right that subdomains which should be able to send mails also need to be declared in my mapfile? My tests with wildcards did not succeed. Acording to the Postfix documentation(1), there is no automatic parent domain lookup. To match parent domains you would need to use regular expression maps. Wietse (1) man 5 postconf | less +/smtpd_sender_login_maps
DSN modification
Hi, I use a content filter that does not accept DSN. = Postfix 25 = FILTER (via content_filter) 10025 = Postfix 10026 = Is it possible to remove the notify=SUCCESS tag in the first postfix and re-insert it in the second one ? I tried to do it with a virtual_maps/pcre couple but it seems it only scans/rewrites the a...@b pattern in the rcpt to field. As if the notify=SUCCESS tag was not seen. Not very surprised but I hoped to have a solution. Thank you Alain
Re: DSN modification
postfix: Hi, I use a content filter that does not accept DSN. Then you'll have to disable DSN announcements by the Postfix SMTP server, as documented in the DSN_README document. Wietse
Re: DSN modification
Hi Thank you for your answer but I do not want to disable the DSN option. I want to temporarly remove the esmtp notify=SUCCESS tag when I pass the message to the content_filter then I want to put it again within the rcpt to field. Doing that (if possible) the next hop relay could use the DSN information. The trouble I have here is that my content filter cuts the global DSN chain. Alain - Original Message - From: test wietse@porcupine.org (Wietse Venema) Date: Friday, March 6, 2009 3:54 pm Subject: Re: DSN modification To: Postfix users postfix-users@postfix.org postfix: Hi, I use a content filter that does not accept DSN. Then you'll have to disable DSN announcements by the Postfix SMTP server, as documented in the DSN_README document. Wietse
Re: DSN modification
postfix: Hi Thank you for your answer but I do not want to disable the DSN option. The Internet RFC is quite clear about this. You must support ALL options (success, fail, delay, none, headers only, full message) or you MUST NOT announce DSN support at all. Wietse
Re: Do not include first 'Received' header when received via 465/587?
LuKreme wrote: On 5-Mar-2009, at 19:15, Noel Jones wrote: Oh, and recent postfix marks authenticated headers; note the ESTMPSA. S = StartTLS, A = Authenticated Received: from [192.168.5.108] (adsl-19-247-14.bna.bellsouth.net [68.19.247.14]) by mgate2.vbhcs.org (Postfix) with ESMTPSA id BAF4A797A6A; Thu, 5 Mar 2009 20:09:39 -0600 (CST) That is very cool, I didn't know that. Of course in my case we're not using TLS, so the header has ESMTPA, but still, quite useful. ... which is why the sample expression is ESTMPS?A, ie. the S is optional. a regexp something like /^(Received: .* myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-$1 should do the trick. I really like that, there's all sorts of possibilities here. Would it be bad to strip out the IPs (usually local/private) from these headers? /^(Received: from )\[\d\d?\d?\.d\d?\d?\.d\d?\d?\.d\d?\d?\](.* myhostname \(Postfix\) with ESMTPS?A .)$/ REPLACE X-$1[internal LAN]$2 /^(Received: from [^\[].* myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-$1 ?? I'm thinking that cleanup is called for all messages, which is why you would only want this on a submission port and not just on the regular cleanup service. Although the Received: from [ip.ip.ip.ip] form never shows up on external mail since bare-ip mailservers are banned anyway. This should be safe to use on all mail - no need for a special cleanup-submission with different header_checks. It should only match on authenticated mail to your server. If you don't want the original IP to show, it's probably better to just remove that part rather than putting a fake IP there. Easy to do by just moving the first parenthesis, something like /^Received: .* (myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-Submitted to $1 That way you at least keep the original QUEUEID. -- Noel Jones
Re: Do not include first 'Received' header when received via 465/587?
On Fri, Mar 06, 2009 at 10:11:24AM -0600, Noel Jones wrote: /^Received: .* (myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-Submitted to $1 That way you at least keep the original QUEUEID. Probably want a : in there to make it a valid header: header_checks.pcre: if /^Received:/ /\n\tby (smtp\.example\.com \(Postfix\) with ESTMPS?A id \w+)/ REPLACE X-Submitted: to $1 endif -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
forward to an external command
Hi, I have postfix with postfixadmin and everything stored in a mysql database. How do I forward emails sent to a mail account to an external command? Please help THanks
Postoffice with virtual mailbox and a Maildrop issue
Hello,
I'm setting up a postoffice platform based on
Postfix+Courier-authlib-Courier-IMAP-Maildrop.
Here my postfix parameters:
# postconf -n
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
append_at_myorigin = no
append_dot_mydomain = no
bounce_size_limit = 1
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
disable_vrfy_command = yes
html_directory = no
local_recipient_maps = $alias_maps, unix:passwd.byname
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 3584
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = posta.domain.tld
myhostname = posta.domain.tld
mynetworks = xxx.yyy.zzz.uuu/27, 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
proxy_read_maps = $virtual_mailbox_domains $virtual_alias_maps
$virtual_mailbox_maps proxy:mysql:/etc/postfix/mysql-virtual-domain.cf
proxy:mysql:/etc/postfix/mysql-virtual-alias.cf
proxy:mysql:/etc/postfix/mysql-virtual-mailbox.cf
queue_directory = /var/spool/postfix
readme_directory = no
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_sasl_auth_enable = no
unknown_local_recipient_reject_code = 550
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual-alias.cf
virtual_gid_maps = static:1021
virtual_mailbox_base = /home/virtual
virtual_mailbox_domains =
proxy:mysql:/etc/postfix/mysql-virtual-domain.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual-mailbox.cf
virtual_transport = maildrop
virtual_uid_maps = static:1021
I have the problem that mail destined to local virtual mailbox is not
delivered locally, even if all looks up succesfully confirm tha the
message have to be delivered locally:
# postmap -q t...@receiver.tld
proxy:mysql:/etc/postfix/mysql-virtual-domain.cf
receiver.tld
# postmap -q test@ receiver.tld
proxy:mysql:/etc/postfix/mysql-virtual-alias.cf
test@ receiver.tld
# postmap -q t...@receiver.tld
proxy:mysql:/etc/postfix/mysql-virtual-mailbox.cf
receiver.tld /test@ receiver.tld/
Indeed it could be a matter of maildrop filter:
maildrop unix - n n - - pipe
flags=Ru user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
But I have also tried to disable it (commenting the lines above in
/etc/postfix/master.cf and commenting the interested lines in
/etc/postfix/main.cf).
Where is the mistake?
Thanks
rocsca
Re: forward to an external command
George wrote: I have postfix with postfixadmin and everything stored in a mysql database. How do I forward emails sent to a mail account to an external command? Since you are using virtual aliases (postfixadmin w/mysql assumes so) you'll need to setup a pipe transport in master.cf and proper settings in /etc/postfix/transports. See the man pages of pipe and transport for more details than what you'll find in this email. virtual alias: foo...@exampe.com foo...@my_custom_transport.example.com add to /etc/postfix/transports: my_custom_transport.example.com my_custom_transport: add to /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transports add to /etc/postfix/master.cf: my_custom_transport unix - n n - - pipe flags=flags_from_pipe_manual user=some_user:some_group argv=/path/to/my_custom_script vars_from_pipe_manual This may be incomplete. It is a rough (very rough?) example of the configuration. I strongly recommend having a look at the pipe and transport manuals before attempting to implement any of this.
Re: Do not include first 'Received' header when received via 465/587?
Victor Duchovni wrote: On Fri, Mar 06, 2009 at 10:11:24AM -0600, Noel Jones wrote: /^Received: .* (myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-Submitted to $1 That way you at least keep the original QUEUEID. Probably want a : in there to make it a valid header: header_checks.pcre: if /^Received:/ /\n\tby (smtp\.example\.com \(Postfix\) with ESTMPS?A id \w+)/ REPLACE X-Submitted: to $1 endif Yes, thanks. -- Noel Jones
Re: Do not include first 'Received' header when received via 465/587?
On Fri, Mar 06, 2009 at 11:33:34AM -0600, Noel Jones wrote: Victor Duchovni wrote: On Fri, Mar 06, 2009 at 10:11:24AM -0600, Noel Jones wrote: /^Received: .* (myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-Submitted to $1 That way you at least keep the original QUEUEID. Probably want a : in there to make it a valid header: header_checks.pcre: if /^Received:/ /\n\tby (smtp\.example\.com \(Postfix\) with ESTMPS?A id \w+)/ REPLACE X-Submitted: to $1 endif Yes, thanks. Note, there may be a spam-score penalty to sending out mail with no Received headers at all. If the MSA sends directly to the outside without going through additional SMTP servers (post-filter, ...), it is probably best to replace just the Received: header IP address, with an RFC-1918 address and leav the received header intact. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: forward to an external command
George wrote: Hi, Please, Do not top post. Reply to the text directly. Thanks for your reply I am sorry but I am not very technical. I am the type of guy that can follow howtos You don't seem to follow J.P.'s example very well. Especially the part about See the man pages of pipe and transport for more details than what you'll find in this email. In the case of Postfix, the documentation is very complete and some howtos are not very helpful. Can you please be more detailed? What is my_custom_transport.example.com ? A subdomain? Yes. In addition, this list uses example.com as a basis quite frequently. You didn't provide your own domain, so J.P. used this as an example. What is my_custom_transport:? The command to which the email is my_custom_transport is a user defined transport in master.cf (as the example shows). forwarded? Is | /path/to/some/php/file: what it needs to be? Is : That format is only valid in an alias map or .forward. Both of which are not used in a virtual mailbox setup. (Virtual mailbox is assumed since you neglected to follow the welcome message.) Brian required in the end? Thanks On Fri, Mar 6, 2009 at 7:20 PM, J.P. Trosclair jptroscl...@judelawfirm.com wrote: George wrote: I have postfix with postfixadmin and everything stored in a mysql database. How do I forward emails sent to a mail account to an external command? Since you are using virtual aliases (postfixadmin w/mysql assumes so) you'll need to setup a pipe transport in master.cf and proper settings in /etc/postfix/transports. See the man pages of pipe and transport for more details than what you'll find in this email. virtual alias: foo...@exampe.com foo...@my_custom_transport.example.com add to /etc/postfix/transports: my_custom_transport.example.com my_custom_transport: add to /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transports add to /etc/postfix/master.cf: my_custom_transport unix - n n - - pipe flags=flags_from_pipe_manual user=some_user:some_group argv=/path/to/my_custom_script vars_from_pipe_manual This may be incomplete. It is a rough (very rough?) example of the configuration. I strongly recommend having a look at the pipe and transport manuals before attempting to implement any of this.
Re: Do not include first 'Received' header when received via 465/587?
On Fri, 6 Mar 2009, Noel Jones wrote: Victor Duchovni wrote: Probably want a : in there to make it a valid header: header_checks.pcre: if /^Received:/ /\n\tby (smtp\.example\.com \(Postfix\) with ESTMPS?A id \w+)/ REPLACE X-Submitted: to $1 endif Yes, thanks. I extrapolated from this, and got something that works perfectly - thanks so much! if /^Received:/ /.*by (hostname \(Postfix\) with ESMTPS?A).*/ REPLACE X-Submitted: to $1 endif My servers do additional processing, and add received headers after this, so no issues with spam filters (as mentioned later in this thread.) Appreciate the help!
Re: Do not include first 'Received' header when received via 465/587?
On Fri, Mar 06, 2009 at 01:16:07PM -0600, Nate Carlson wrote: On Fri, 6 Mar 2009, Noel Jones wrote: Victor Duchovni wrote: Probably want a : in there to make it a valid header: header_checks.pcre: if /^Received:/ /\n\tby (smtp\.example\.com \(Postfix\) with ESTMPS?A id \w+)/ REPLACE X-Submitted: to $1 endif Yes, thanks. I extrapolated from this, and got something that works perfectly - thanks so much! if /^Received:/ /.*by (hostname \(Postfix\) with ESMTPS?A).*/ REPLACE X-Submitted: to $1 endif Replace the .* with \n\t or \012\011 if not PCRE and you are losing the queue-id, which is very useful for later trouble-shoots. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Plus addressing not delivering to folder
On Fri, Mar 06, 2009 at 02:27:56PM -0500, Charles Marcus wrote: It would be nice if the postfix local and/or virtual DA master.cf entries allowed the addition of these flags to be able to do this... I guess in this situation I'll have to wait until I have converted to dovecot so I can use its LDA... The whole concept of sub-folder is IMAP-server specific. Postfix does not know how your IMAP server works, that's why you should use LMTP or the delivery agent for your IMAP server. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Do not include first 'Received' header when received via 465/587?
Victor Duchovni: On Fri, Mar 06, 2009 at 01:16:07PM -0600, Nate Carlson wrote: On Fri, 6 Mar 2009, Noel Jones wrote: Victor Duchovni wrote: Probably want a : in there to make it a valid header: header_checks.pcre: if /^Received:/ /\n\tby (smtp\.example\.com \(Postfix\) with ESTMPS?A id \w+)/ REPLACE X-Submitted: to $1 endif Yes, thanks. I extrapolated from this, and got something that works perfectly - thanks so much! if /^Received:/ /.*by (hostname \(Postfix\) with ESMTPS?A).*/ REPLACE X-Submitted: to $1 endif Replace the .* with \n\t or \012\011 if not PCRE and you are losing the queue-id, which is very useful for later trouble-shoots. The .* are always unnecessary at the start and end of a pattern. Also, he is replacing the entire header, not the middle portion. Therefore the following will suffice: if /^Received:/ /\s+(host\.example\.com \(Postfix\) with ESMTPS?A id \w+)/ REPLACE X-Submitted: to $1 endif Wietse
Re: Plus addressing not delivering to folder
Charles Marcus: Obviously (also judging from the replies so far), the postfix DA's don't support adding flags to accomplish this, like you can with the dovecot LDA master.cf entry. So, an obvious follow-up would be, is there a reason postfix's DAs don't support this? I'm not complaining, just asking... :) If you want a specific server's IMAP folder features, use the delivery agent that was written for that IMAP server. It makes no sense to copy code from every IMAP server into Postfix. Wietse
Re: forward to an external command
What is my_custom_transport.example.com ? A subdomain? Yes. In addition, this list uses example.com as a basis quite frequently. You didn't provide your own domain, so J.P. used this as an example. As a side note, it doesn't have to be a real sub-domain. When the mail is handed off to postfix my_custom_transport.example.com will be found in the transport_maps table since you defined it there (or will soon enough) along with my_custom_transport. From there postfix will try to deliver the mail using the definition of my_custom_transport in master.cf. I'm sure some folks can get into more details than I can on what really happens, but in a nutshell this is how things will flow. When you create your pseudo domain for use in this setup, it's probably best to use a non existent sub-domain or some variant of your real domain just to help avoid confusion or complications down the road. This is not guaranteed to prevent problems, but in my opinion it's a good first step to avoiding them. I haven't personally seen a best practices guide for these sorts of situations. Just don't call your pseudo domain (gmail|yahoo|hotmail).com or some other real domain that accepts mail.
Re: Plus addressing not delivering to folder
On 6-Mar-2009, at 12:27, Charles Marcus wrote:
Hmmm... I'm now wondering if ${extension} can somehow be used with the
virtual_mailbox_maps query to accomplish what I want?
Yes, but you need procmail (or, I assume, Maildrop)
in a procmail file you would have:
# based on the procmail pipe in master.cf
ARG=$EXTENSION
# For non virtual users
# ARG=$1
:0
* ! ARG
.$ARG/
as the simplest example. Getting procmail working with virtual users
is a little tricky. Here's what I have:
/etc/postfix/main.cf
virtual_transport = procmail
/etc/postfix/master.cf
procmail unix - n n - - pipe
-o flags=uhFORD user=vpopmail argv=/usr/local/bin/procmail -t -m
USER=${recipient} EXTENSION=${extension} /usr/local/etc/
procmailrc.common
--
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Re: Postoffice with virtual mailbox and a Maildrop issue
On Friday, March 06, 2009 at 18:15 CET,
Rocco Scappatura rocco.scappat...@infracom.it wrote:
[...]
append_at_myorigin = no
This is not supported by Postfix. Use it at your own peril.
[...]
I have the problem that mail destined to local virtual mailbox is not
delivered locally, even if all looks up succesfully confirm tha the
message have to be delivered locally:
So what does happen to the messages?
# postmap -q t...@receiver.tld
proxy:mysql:/etc/postfix/mysql-virtual-domain.cf
receiver.tld
virtual_mailbox_domains is looked up with the domain name as the key,
not the email address. Show the output from the right command.
[...]
Indeed it could be a matter of maildrop filter:
maildrop unix - n n - - pipe
flags=Ru user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
But I have also tried to disable it (commenting the lines above
in /etc/postfix/master.cf and commenting the interested lines in
/etc/postfix/main.cf).
Disabling an unused service seldom makes any difference.
--
Magnus Bäck
mag...@dsek.lth.se
Re: forward to an external command
Hi, Thanks all for your help. If anyone needs this in future, here's how I did it: 1. Added the following line to /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport 2. create a subdomain like(postfixadmin does not allow to add an alias to a not existing domain): command1.domain.org 2. go to postfixadmin and create the alias like this: Alias: recipi...@domain.org To: anyth...@command1.domain.org 3. edit /etc/postfix/transport and add like this: anyth...@command1.domain.org some_name: 4. run: postmap /etc/postfix/transport 5. edit /etc/postfix/master.cf and add like this: some_name unix - n n - - pipe user=SOMEUSER argv=/path/to/php/script 6. run: postfix reload On Fri, Mar 6, 2009 at 9:42 PM, J.P. Trosclair jptroscl...@judelawfirm.com wrote: What is my_custom_transport.example.com ? A subdomain? Yes. In addition, this list uses example.com as a basis quite frequently. You didn't provide your own domain, so J.P. used this as an example. As a side note, it doesn't have to be a real sub-domain. When the mail is handed off to postfix my_custom_transport.example.com will be found in the transport_maps table since you defined it there (or will soon enough) along with my_custom_transport. From there postfix will try to deliver the mail using the definition of my_custom_transport in master.cf. I'm sure some folks can get into more details than I can on what really happens, but in a nutshell this is how things will flow. When you create your pseudo domain for use in this setup, it's probably best to use a non existent sub-domain or some variant of your real domain just to help avoid confusion or complications down the road. This is not guaranteed to prevent problems, but in my opinion it's a good first step to avoiding them. I haven't personally seen a best practices guide for these sorts of situations. Just don't call your pseudo domain (gmail|yahoo|hotmail).com or some other real domain that accepts mail.
Re: Plus addressing not delivering to folder
On 3/6/2009 3:43 PM, LuKreme wrote:
On 6-Mar-2009, at 12:27, Charles Marcus wrote:
Hmmm... I'm now wondering if ${extension} can somehow be used with the
virtual_mailbox_maps query to accomplish what I want?
Yes, but you need procmail (or, I assume, Maildrop)
Many thanks for the detail... but with Victor and Wietse's responses, I
think the 2x4 is no longer needed... :)
Procmail is not a beast I want to unleash on my server, so, since the
conversion to dovecot is probably not far away (I'm waiting for 1.2),
I'll just wait for that...
Thanks again for straightening me out...
--
Best regards,
Charles
Re: Plus addressing not delivering to folder
Charles Marcus wrote, at 03/06/2009 02:27 PM: I want to be able to use plussed addresses in such a way that if such a message comes in and a subfolder matches the extension, the message will be delivered to that subfolder, and if there is no matching subfolder, it is just delivered to the Inbox. Cyrus IMAPd supports this behaviour.
