I have recipient_delimiter = + in main.cf (Postfix). But deliveries to dovecot/deliver are still being rejected. It appears that the full email is still in the envelope (e.g. phil+howard@example.com which I want to be delivered to phil@example.com). Is that how it's supposed to work and Dovecot just doesn't support this?
On 2010-05-26 4:20 PM, Phil Howard wrote:
I have recipient_delimiter = + in main.cf (Postfix). But deliveries to dovecot/deliver are still being rejected. It appears that the full email is still in the envelope (e.g. phil+howard@example.com which I want to be delivered to phil@example.com). Is that how it's supposed to work and Dovecot just doesn't support this?
postconf -n output and logs can be helpful...
--
Best regards,
Charles
On Wed, 26 May 2010 16:20:06 -0400 Phil Howard <ttiphil@gmail.com> articulated:
I have recipient_delimiter = + in main.cf (Postfix). But deliveries to dovecot/deliver are still being rejected. It appears that the full email is still in the envelope (e.g. phil+howard@example.com which I want to be delivered to phil@example.com). Is that how it's supposed to work and Dovecot just doesn't support this?
On or about line 821 in the Dovecot.conf file:
#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
If you have not all ready done so, add the "+" to the end of the list and un-comment the line. I believe you will have to restart 'dovecot' for the change to take affect.
By the way, Postfix must be properly configured to pass the email address to dovecot. I leave that as an exercise to the user. You might want to start here thought:
http://wiki.dovecot.org/LDA/Postfix-- Jerry Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
XML is a giant step in no direction at all.
Erik NaggumOn 2010-05-26 1:59 PM, Jerry wrote:
On Wed, 26 May 2010 16:20:06 -0400 Phil Howard <ttiphil@gmail.com> articulated:
I have recipient_delimiter = + in main.cf (Postfix). But deliveries to dovecot/deliver are still being rejected. It appears that the full email is still in the envelope (e.g. phil+howard@example.com which I want to be delivered to phil@example.com). Is that how it's supposed to work and Dovecot just doesn't support this?
On or about line 821 in the Dovecot.conf file:
#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
If you have not all ready done so, add the "+" to the end of the list and un-comment the line. I believe you will have to restart 'dovecot' for the change to take affect.
By the way, Postfix must be properly configured to pass the email address to dovecot. I leave that as an exercise to the user. You might want to start here thought:
I've never had to touch auth_username_chars to get this to work.
In main.cf, I've set:
mailbox_transport = dovecot recipient_delimiter = +
And in master.cf:
# Dovecot dovecot unix - n n - - pipe flags=DR user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${user} -a ${recipient} -n -m ${extension}
I may not need all the options to deliver, but this does work nice. One thing I did notice is that I needed to add the %L arg in my passdb and userdb definitions in my dovecot.conf in order to make the mailbox name case insensitive:
passdb: driver: passwd-file args: username_format=%Ln /etc/dovecot/passwd userdb: driver: static args: uid=500 gid=500 home=/srv/dovecot/%Ln
-Greg
On Thu, May 27, 2010 at 10:50, Gregory Finch <gfinch@ldmltd.ca> wrote:
I've never had to touch auth_username_chars to get this to work.
In main.cf, I've set:
mailbox_transport = dovecot
I have virtual_transport = dovecot
recipient_delimiter = +
I have that now (didn't when I initially set up the server assuming it was a default, but later added it)
And in master.cf:
# Dovecot dovecot unix - n n - - pipe flags=DR user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${user} -a ${recipient} -n -m ${extension}
Mine is a bit different:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop}
I'm still not sure what "nexthop" means but it seems to make it work.
I may not need all the options to deliver, but this does work nice. One thing I did notice is that I needed to add the %L arg in my passdb and userdb definitions in my dovecot.conf in order to make the mailbox name case insensitive:
passdb: driver: passwd-file args: username_format=%Ln /etc/dovecot/passwd userdb: driver: static args: uid=500 gid=500 home=/srv/dovecot/%Ln
================================================================ # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.31-19-server x86_64 Ubuntu 9.10 ext3 base_dir: /var/run/dovecot/ log_path: /var/log/dovecot/error.log info_log_path: /var/log/dovecot/info.log log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap pop3 imaps pop3s listen: 172.30.0.24, [fc00::18], 127.0.0.1, [::1] ssl_cert_file: /etc/ssl/certs/imap.example.com.crt ssl_key_file: /etc/ssl/private/imap.example.com.key ssl_parameters_regenerate: 24 ssl_cipher_list: ALL:!LOW:!SSLv2:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:+HIGH:+MEDIUM login_dir: /var/run/dovecot//login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_greeting: AUTHORIZED USERS ONLY -- unauthorized access strictly prohibited login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no mail_max_userip_connections(default): 10 mail_max_userip_connections(imap): 10 mail_max_userip_connections(pop3): 3 verbose_proctitle: yes first_valid_uid: 250 mail_privileged_group: mail mail_uid: vmail mail_gid: vmail mail_location: maildir:/home/mail/%Ld/%Ln/mail mail_debug: yes mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_process_size: 768 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh auth default: mechanisms: plain login username_chars: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@+ username_format: %Ln@%Ld verbose: yes debug: yes debug_passwords: yes passdb: driver: passwd-file args: username_format=%Ln@%Ld /etc/mailauth/deny deny: yes passdb: driver: passwd-file args: username_format=%Ln /etc/mailauth/%Ld/deny deny: yes passdb: driver: passwd-file args: scheme=crypt username_format=%Ln@%Ld /etc/mailauth/passwd passdb: driver: passwd-file args: scheme=crypt username_format=%Ln /etc/mailauth/%Ld/passwd userdb: driver: passwd-file args: username_format=%Ln@%Ld /etc/mailauth/passwd userdb: driver: passwd-file args: username_format=%Ln /etc/mailauth/%Ld/passwd socket: type: listen client: path: /var/spool/postfix/private/dovecot-auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail
alias_database = cdb:/etc/postfix/aliases alias_maps = cdb:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix default_destination_concurrency_limit = 2 default_privs = nobody in_flow_delay = 1s inet_protocols = ipv4, ipv6 local_destination_concurrency_limit = 2 mail_owner = postfix mydomain = example.com myhostname = mx.example.com mynetworks = 127.0.0.0/8, 172.16.0.0/16, 172.20.0.0/16, 172.30.0.0/16, [::1]/128, [fc00::]/48, [fe80::]/48 myorigin = $mydomain proxy_interfaces = MY OUTSIDE IP queue_directory = /var/spool/postfix recipient_delimiter = - smtp_bind_address = 172.30.0.25 smtp_bind_address6 = fc00::25 smtpd_banner = $myhostname ESMTP - UNSOLICITED BULK OR ILLEGAL EMAIL IS STRICTLY PROHIBITED smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/dovecot-auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/smtp.example.com.crt smtpd_tls_key_file = /etc/ssl/private/smtp.example.com.key smtpd_tls_security_level = may soft_bounce = yes unknown_local_recipient_reject_code = 450 virtual_alias_maps = cdb:/etc/postfix/virtual virtual_mailbox_domains = BIG LIST OF DOMAINS REDACTED virtual_transport = dovecot
On 2010-05-27 8:27 AM, Phil Howard wrote:
On Thu, May 27, 2010 at 10:50, Gregory Finch <gfinch@ldmltd.ca> wrote:
I've never had to touch auth_username_chars to get this to work.
In main.cf, I've set:
mailbox_transport = dovecot
I have virtual_transport = dovecot
recipient_delimiter = +
I have that now (didn't when I initially set up the server assuming it was a default, but later added it)
And in master.cf:
# Dovecot dovecot unix - n n - - pipe flags=DR user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${user} -a ${recipient} -n -m ${extension}
Mine is a bit different:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop}
I'm still not sure what "nexthop" means but it seems to make it work.
I may not need all the options to deliver, but this does work nice. One thing I did notice is that I needed to add the %L arg in my passdb and userdb definitions in my dovecot.conf in order to make the mailbox name case insensitive:
passdb: driver: passwd-file args: username_format=%Ln /etc/dovecot/passwd userdb: driver: static args: uid=500 gid=500 home=/srv/dovecot/%Ln
================================================================ # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.31-19-server x86_64 Ubuntu 9.10 ext3 base_dir: /var/run/dovecot/ log_path: /var/log/dovecot/error.log info_log_path: /var/log/dovecot/info.log log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap pop3 imaps pop3s listen: 172.30.0.24, [fc00::18], 127.0.0.1, [::1] ssl_cert_file: /etc/ssl/certs/imap.example.com.crt ssl_key_file: /etc/ssl/private/imap.example.com.key ssl_parameters_regenerate: 24 ssl_cipher_list: ALL:!LOW:!SSLv2:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:+HIGH:+MEDIUM login_dir: /var/run/dovecot//login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_greeting: AUTHORIZED USERS ONLY -- unauthorized access strictly prohibited login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no mail_max_userip_connections(default): 10 mail_max_userip_connections(imap): 10 mail_max_userip_connections(pop3): 3 verbose_proctitle: yes first_valid_uid: 250 mail_privileged_group: mail mail_uid: vmail mail_gid: vmail mail_location: maildir:/home/mail/%Ld/%Ln/mail mail_debug: yes mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_process_size: 768 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh auth default: mechanisms: plain login username_chars: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@+ username_format: %Ln@%Ld verbose: yes debug: yes debug_passwords: yes passdb: driver: passwd-file args: username_format=%Ln@%Ld /etc/mailauth/deny deny: yes passdb: driver: passwd-file args: username_format=%Ln /etc/mailauth/%Ld/deny deny: yes passdb: driver: passwd-file args: scheme=crypt username_format=%Ln@%Ld /etc/mailauth/passwd passdb: driver: passwd-file args: scheme=crypt username_format=%Ln /etc/mailauth/%Ld/passwd userdb: driver: passwd-file args: username_format=%Ln@%Ld /etc/mailauth/passwd userdb: driver: passwd-file args: username_format=%Ln /etc/mailauth/%Ld/passwd socket: type: listen client: path: /var/spool/postfix/private/dovecot-auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail
alias_database = cdb:/etc/postfix/aliases alias_maps = cdb:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix default_destination_concurrency_limit = 2 default_privs = nobody in_flow_delay = 1s inet_protocols = ipv4, ipv6 local_destination_concurrency_limit = 2 mail_owner = postfix mydomain = example.com myhostname = mx.example.com mynetworks = 127.0.0.0/8, 172.16.0.0/16, 172.20.0.0/16, 172.30.0.0/16, [::1]/128, [fc00::]/48, [fe80::]/48 myorigin = $mydomain proxy_interfaces = MY OUTSIDE IP queue_directory = /var/spool/postfix recipient_delimiter = - ^^ do you mean to have a + here instead?
smtp_bind_address = 172.30.0.25 smtp_bind_address6 = fc00::25 smtpd_banner = $myhostname ESMTP - UNSOLICITED BULK OR ILLEGAL EMAIL IS STRICTLY PROHIBITED smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/dovecot-auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/smtp.example.com.crt smtpd_tls_key_file = /etc/ssl/private/smtp.example.com.key smtpd_tls_security_level = may soft_bounce = yes unknown_local_recipient_reject_code = 450 virtual_alias_maps = cdb:/etc/postfix/virtual virtual_mailbox_domains = BIG LIST OF DOMAINS REDACTED virtual_transport = dovecot
May 27 11:00:02 eth0 postfix/pipe[25377]: DCA7868417: to=<phil+howard@example.com>, relay=dovecot, delay=0.27, delays=0.21/0.01/0/0.05, dsn=4.1.1, status=SOFTBOUNCE (user unknown)
the errors in your other email suggest (to me, I could be way off base) that postfix isn't finding <phil+howard@example.com> as a local recipient. This might have to do with the delimiter though.
-Greg
On Thu, May 27, 2010 at 12:52, Gregory Finch <gfinch@ldmltd.ca> wrote:
On 2010-05-27 8:27 AM, Phil Howard wrote:
On Thu, May 27, 2010 at 10:50, Gregory Finch <gfinch@ldmltd.ca> wrote:
I've never had to touch auth_username_chars to get this to work.
In main.cf, I've set:
mailbox_transport = dovecot
I have virtual_transport = dovecot
recipient_delimiter = +
I have that now (didn't when I initially set up the server assuming it was a default, but later added it)
And in master.cf:
# Dovecot dovecot unix - n n - - pipe flags=DR user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${user} -a ${recipient} -n -m ${extension}
Mine is a bit different:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop}
I'm still not sure what "nexthop" means but it seems to make it work.
I may not need all the options to deliver, but this does work nice. One thing I did notice is that I needed to add the %L arg in my passdb and userdb definitions in my dovecot.conf in order to make the mailbox name case insensitive:
passdb: driver: passwd-file args: username_format=%Ln /etc/dovecot/passwd userdb: driver: static args: uid=500 gid=500 home=/srv/dovecot/%Ln
================================================================ # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.31-19-server x86_64 Ubuntu 9.10 ext3 base_dir: /var/run/dovecot/ log_path: /var/log/dovecot/error.log info_log_path: /var/log/dovecot/info.log log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap pop3 imaps pop3s listen: 172.30.0.24, [fc00::18], 127.0.0.1, [::1] ssl_cert_file: /etc/ssl/certs/imap.example.com.crt ssl_key_file: /etc/ssl/private/imap.example.com.key ssl_parameters_regenerate: 24 ssl_cipher_list: ALL:!LOW:!SSLv2:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:+HIGH:+MEDIUM login_dir: /var/run/dovecot//login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_greeting: AUTHORIZED USERS ONLY -- unauthorized access strictly prohibited login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no mail_max_userip_connections(default): 10 mail_max_userip_connections(imap): 10 mail_max_userip_connections(pop3): 3 verbose_proctitle: yes first_valid_uid: 250 mail_privileged_group: mail mail_uid: vmail mail_gid: vmail mail_location: maildir:/home/mail/%Ld/%Ln/mail mail_debug: yes mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_process_size: 768 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh auth default: mechanisms: plain login username_chars: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@+ username_format: %Ln@%Ld verbose: yes debug: yes debug_passwords: yes passdb: driver: passwd-file args: username_format=%Ln@%Ld /etc/mailauth/deny deny: yes passdb: driver: passwd-file args: username_format=%Ln /etc/mailauth/%Ld/deny deny: yes passdb: driver: passwd-file args: scheme=crypt username_format=%Ln@%Ld /etc/mailauth/passwd passdb: driver: passwd-file args: scheme=crypt username_format=%Ln /etc/mailauth/%Ld/passwd userdb: driver: passwd-file args: username_format=%Ln@%Ld /etc/mailauth/passwd userdb: driver: passwd-file args: username_format=%Ln /etc/mailauth/%Ld/passwd socket: type: listen client: path: /var/spool/postfix/private/dovecot-auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail
alias_database = cdb:/etc/postfix/aliases alias_maps = cdb:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix default_destination_concurrency_limit = 2 default_privs = nobody in_flow_delay = 1s inet_protocols = ipv4, ipv6 local_destination_concurrency_limit = 2 mail_owner = postfix mydomain = example.com myhostname = mx.example.com mynetworks = 127.0.0.0/8, 172.16.0.0/16, 172.20.0.0/16, 172.30.0.0/16, [::1]/128, [fc00::]/48, [fe80::]/48 myorigin = $mydomain proxy_interfaces = MY OUTSIDE IP queue_directory = /var/spool/postfix recipient_delimiter = - ^^ do you mean to have a + here instead?
Well, it is coded as a + in my master copy distributed to the servers. I didn't notice that and will need to check and see what is happening. Maybe it's coded twice or something.
the errors in your other email suggest (to me, I could be way off base) that postfix isn't finding <phil+howard@example.com> as a local recipient. This might have to do with the delimiter though.
The messages suggest it is trying to send it to Dovecot. That is "local" as far as I'm concerned (but what is "local" ... some people I've found insist that the only way something is local is if it is delivered to a system shell user by the MTA itself, and not by an alternate delivery agent even if it goes into the same filesystem). So when someone says "local" I really don't know for sure what is meant.
On 2010-05-27 1:42 PM, Phil Howard wrote:
Yup, there was a 2nd setting nearly at the bottom of the file, and it was different. Thanks for catching that.
This is why you *always* go by what output pof postconf -n says, not what you think you put in main.cf.
You wasted a lot of time (yours and others here) on that unnecessarily...
--
Best regards,
Charles
On Fri, May 28, 2010 at 09:55, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2010-05-27 1:42 PM, Phil Howard wrote:
Yup, there was a 2nd setting nearly at the bottom of the file, and it was different. Thanks for catching that.
This is why you *always* go by what output pof postconf -n says, not what you think you put in main.cf.
You wasted a lot of time (yours and others here) on that unnecessarily...
My main.cf file has the comments (my own that explains why settings are there, not the default comments). It is the easier to read file. Even then, I was also reading the postconf -n output and just didn't see the subtle difference (I was thinking more along the lines of "what else is needed"). What might be needed to avoid things like this is something to compare them. Or maybe postfix giving an error when a conflicting setting is encountered (or is there some basis for always allowing settings that change previous settings).
On Fri, 28 May 2010 11:25:17 -0400 Phil Howard <ttiphil@gmail.com> articulated:
My main.cf file has the comments (my own that explains why settings are there, not the default comments). It is the easier to read file. Even then, I was also reading the postconf -n output and just didn't see the subtle difference (I was thinking more along the lines of "what else is needed"). What might be needed to avoid things like this is something to compare them. Or maybe postfix giving an error when a conflicting setting is encountered (or is there some basis for always allowing settings that change previous settings).
In the Postfix "main.cf" file, the last entry wins. This is one of the reasons to use "postconf -n" and NOT what you think the correct entry is. The output of "postconf -n" shows what Postfix sees.
To sum it up:
Provide output from the postfinger tool. This can be found at http://ftp.wl0.org/SOURCES/postfinger.
If the problem is SASL related, consider including the output from the saslfinger tool. This can be found at http://postfix.state-of-mind.de/patrick.koetter/saslfinger/.
If the problem is about too much mail in the queue, consider including output from the qshape tool, as described in the QSHAPE_README file.
If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document.
-- Jerry Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
On Fri, May 28, 2010 at 12:11, Jerry <dovecot.user@seibercom.net> wrote:
On Fri, 28 May 2010 11:25:17 -0400 Phil Howard <ttiphil@gmail.com> articulated:
My main.cf file has the comments (my own that explains why settings are there, not the default comments). It is the easier to read file. Even then, I was also reading the postconf -n output and just didn't see the subtle difference (I was thinking more along the lines of "what else is needed"). What might be needed to avoid things like this is something to compare them. Or maybe postfix giving an error when a conflicting setting is encountered (or is there some basis for always allowing settings that change previous settings).
In the Postfix "main.cf" file, the last entry wins. This is one of the reasons to use "postconf -n" and NOT what you think the correct entry is. The output of "postconf -n" shows what Postfix sees.
To sum it up:
Provide output from the postfinger tool. This can be found at http://ftp.wl0.org/SOURCES/postfinger.
If the problem is SASL related, consider including the output from the saslfinger tool. This can be found at http://postfix.state-of-mind.de/patrick.koetter/saslfinger/.
If the problem is about too much mail in the queue, consider including output from the qshape tool, as described in the QSHAPE_README file.
If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document.
Have you seen any config check tools?
On 2010-05-28 1:00 PM, Phil Howard wrote:
If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document.
Have you seen any config check tools?
Yes - it's called a brain. ;)
Seriously - only you know your environment well enough to evaluate any given config.
Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output.
--
Best regards,
Charles
On Fri, May 28, 2010 at 14:06, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2010-05-28 1:00 PM, Phil Howard wrote:
If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document.
Have you seen any config check tools?
Yes - it's called a brain. ;)
I think you are missing the point. A config check tool would be sifting through the details of the main.cf file, and the postconf-n.out file, and reporting the difference between what one thinks they have configured and what Postfix understands the configuration to be.
Seriously - only you know your environment well enough to evaluate any given config.
I think you are missing the point. Since what Postfix uses as the configuration isn't guaranteed to be what is coded ... because config items do get changed by subsequent config items ... a tool that can compare things comes in valuable. We all know that doing things in less time is a good thing (or else there would be not complaint about wasting time). But manually sifting through two files, point by point, and cross checking everything, every time, is as much, or more, of a time waster. And given that it would be done quite often, one is wasting a lot of time if they carry out that process. This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf), and just produce the warnings ... "hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that".
Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output.
But it doesn't complain for conflict errors. And that was the class of error that happened.
On Fri, 28 May 2010 14:18:06 -0400 Phil Howard <ttiphil@gmail.com> articulated:
On Fri, May 28, 2010 at 14:06, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2010-05-28 1:00 PM, Phil Howard wrote:
If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document.
Have you seen any config check tools?
Yes - it's called a brain. ;)
I think you are missing the point. A config check tool would be sifting through the details of the main.cf file, and the postconf-n.out file, and reporting the difference between what one thinks they have configured and what Postfix understands the configuration to be.
You are missing the point. Postfix sees what the output of "postfix -d" displays unless modified. Those modifications are what "postfix -n" displays. This is not taking into consideration any modifications done in "master.cf" obviously.
Seriously - only you know your environment well enough to evaluate any given config.
I think you are missing the point. Since what Postfix uses as the configuration isn't guaranteed to be what is coded ...
"Scratching Head" If you configured it, Postfix will either use it or log an error regarding it. That I can guarantee (Been there before)
because config items do get changed by subsequent config items ... a tool that can compare things comes in valuable. We all know that doing things in less time is a good thing (or else there would be not complaint about wasting time). But manually sifting through two files, point by point, and cross checking everything, every time, is as much, or more, of a time waster. And given that it would be done quite often, one is wasting a lot of time if they carry out that process.
Exactly what type of system are you trying to support? I fail to understand why you are constantly changing the base Postfix configuration. I add/delete users on a virtually daily basis, however, once my basic Postifx configuration was setup, I have had no reason to mess with it. If you are modifying it on a daily basis, you are probably doing something wrong.
This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf), and just produce the warnings ... "hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that".
Correct, you can only have the last one (Postfix). I am not sure about Dovecot. Then again, I don't enter rules haphazardly.
Again, the output of "postconf -n" is what Postfix sees and understands. If you think you have duplicate values in the file, try 'grep' to locate them. It doesn't make any difference though since the last one wins no matter what.
NOTE: One known exception is:
dovecot_destination_recipient_limit = 1This does not display with "postconf -n". Wietse once explained why; however, I don't remember why any more. By the way, if you are doing virtual delivery with Postfix/Dovecot, you should probably have that in the "main.cf" file. As always, YMMV.
Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output.
But it doesn't complain for conflict errors. And that was the class of error that happened.
What conflict error? It would not happen in Postfix's "main.cf" file.
-- Jerry Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
On Fri, May 28, 2010 at 15:28, Jerry <dovecot.user@seibercom.net> wrote:
Exactly what type of system are you trying to support? I fail to understand why you are constantly changing the base Postfix configuration. I add/delete users on a virtually daily basis, however, once my basic Postifx configuration was setup, I have had no reason to mess with it. If you are modifying it on a daily basis, you are probably doing something wrong.
One that is just getting started. I expect to get to a point where I don't need to modify it. Not there, yet. We needed to get going on this sooner than originally planned, so not everything is in place, yet. For example, spam and virus trapping are still to do (next [*]). And tweaks are still possible for things like file locations as automation processes are added (later). I bet you have those thing already in place and thus don't need to change it.
[*] Still trying to figure out how to make SpamAssassin put what it thinks is spam into an incoming spam box, rather than the usual INBOX (also seeking to find what name of such a box most people use). And that's in addition to another mailbox which users will move spam to, that comes into their INBOX, to be extracted at the server for training.
This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf), and just produce the warnings ... "hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that".
Correct, you can only have the last one (Postfix). I am not sure about Dovecot. Then again, I don't enter rules haphazardly.
Dovecot has sections and can do multiple sections. This is the Dovecot mailing list so you can ask about it here.
Again, the output of "postconf -n" is what Postfix sees and understands. If you think you have duplicate values in the file, try 'grep' to locate them. It doesn't make any difference though since the last one wins no matter what.
NOTE: One known exception is:
dovecot_destination_recipient_limit = 1
This does not display with "postconf -n". Wietse once explained why; however, I don't remember why any more. By the way, if you are doing virtual delivery with Postfix/Dovecot, you should probably have that in the "main.cf" file. As always, YMMV.
I'm assuming because it is a dynamically named setting for a transport.
Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output.
But it doesn't complain for conflict errors. And that was the class of error that happened.
What conflict error? It would not happen in Postfix's "main.cf" file.
Two like settings, where one would not be used, regardless of which (whether it's a first setting wins or a last setting wins system), is a conflict in my book. I'd have made the system flag it as an error (except maybe if both settings would have the exact same effect) and maybe not even start up.
If postconf -n carried comments along, then it could be used as a config linter ... let it's output replace the original and that will be the one to edit for the next change.
On 2010-05-28 4:49 PM, Phil Howard wrote:
If postconf -n carried comments along, then it could be used as a config linter ... let it's output replace the original and that will be the one to edit for the next change.
The whole purpose of the -n output is to provide clean, easy to read *settings* as seen by postfix (as opposed to comments that are meant for people).
--
Best regards,
Charles
On Fri, May 28, 2010 at 16:53, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2010-05-28 4:49 PM, Phil Howard wrote:
If postconf -n carried comments along, then it could be used as a config linter ... let it's output replace the original and that will be the one to edit for the next change.
The whole purpose of the -n output is to provide clean, easy to read *settings* as seen by postfix (as opposed to comments that are meant for people).
So you are saying that this is not meant for people?
On 2010-05-28 5:01 PM, Phil Howard wrote:
On Fri, May 28, 2010 at 16:53, Charles Marcus wrote:
The whole purpose of the -n output is to provide clean, easy to read *settings* as seen by postfix (as opposed to comments that are meant for people).
So you are saying that this is not meant for people?
<sigh> yeah, so I worded it badly...
Of course it is meant for people, but it is meant to show only the bare minimum of what postfix sees as the settings. It is left up to you, the sys admin, to be able to interpret the data as presented, bearing in mind all caveats (ie, that last setting wins)...
--
Best regards,
Charles
On Fri, May 28, 2010 at 17:30, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2010-05-28 5:01 PM, Phil Howard wrote:
On Fri, May 28, 2010 at 16:53, Charles Marcus wrote:
The whole purpose of the -n output is to provide clean, easy to read *settings* as seen by postfix (as opposed to comments that are meant for people).
So you are saying that this is not meant for people?
<sigh> yeah, so I worded it badly...
Of course it is meant for people, but it is meant to show only the bare minimum of what postfix sees as the settings. It is left up to you, the sys admin, to be able to interpret the data as presented, bearing in mind all caveats (ie, that last setting wins)...
And that caveat was something I was not aware of, as it is an usual method.
On 2010-06-01 8:39 AM, Phil Howard wrote:
On Fri, May 28, 2010 at 17:30, Charles Marcus wrote:
Of course it is meant for people, but it is meant to show only the bare minimum of what postfix sees as the settings. It is left up to you, the sys admin, to be able to interpret the data as presented, bearing in mind all caveats (ie, that last setting wins)...
And that caveat was something I was not aware of, as it is an usual method.
That's why reading man pages is usually a good idea... ;)
--
Best regards,
Charles
On Tue, Jun 1, 2010 at 09:56, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2010-06-01 8:39 AM, Phil Howard wrote:
On Fri, May 28, 2010 at 17:30, Charles Marcus wrote:
Of course it is meant for people, but it is meant to show only the bare minimum of what postfix sees as the settings. It is left up to you, the sys admin, to be able to interpret the data as presented, bearing in mind all caveats (ie, that last setting wins)...
And that caveat was something I was not aware of, as it is an usual method.
That's why reading man pages is usually a good idea... ;)
Yes. And if Postfix were not such a large and complex MTA (not that others aren't), and if the complexities of getting things working between Postfix and Dovecot were not so hard (if Postfix and Dovecot had supported a common file format for listing users and their crypt passwords, this would have taken a lot less of my time), I might have had time to read it all. Unfortunately, working at a startup does not afford such luxury.
Postfix's great advantage is that it supports so many ways to do things.
Postfix's great disadvantage is that it supports so many ways to do things.
I should have also just blown off all the people trying to get me to use SQL and such, instead of debating them (which was just a waste of time).
On Tue, 1 Jun 2010 10:09:19 -0400 Phil Howard <ttiphil@gmail.com> articulated:
On Tue, Jun 1, 2010 at 09:56, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2010-06-01 8:39 AM, Phil Howard wrote:
On Fri, May 28, 2010 at 17:30, Charles Marcus wrote:
Of course it is meant for people, but it is meant to show only the bare minimum of what postfix sees as the settings. It is left up to you, the sys admin, to be able to interpret the data as presented, bearing in mind all caveats (ie, that last setting wins)...
And that caveat was something I was not aware of, as it is an usual method.
That's why reading man pages is usually a good idea... ;)
Yes. And if Postfix were not such a large and complex MTA (not that others aren't), and if the complexities of getting things working between Postfix and Dovecot were not so hard (if Postfix and Dovecot had supported a common file format for listing users and their crypt passwords, this would have taken a lot less of my time), I might have had time to read it all. Unfortunately, working at a startup does not afford such luxury.
Postfix's great advantage is that it supports so many ways to do things.
Postfix's great disadvantage is that it supports so many ways to do things.
I should have also just blown off all the people trying to get me to use SQL and such, instead of debating them (which was just a waste of time).
I have and use common data bases in MySQL that are shared between Postfix & Dovecot. Of course, it has to be properly designed.
-- Jerry Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
On 2010-05-28 2:18 PM, Phil Howard wrote:
On Fri, May 28, 2010 at 14:06, Charles Marcus wrote:
On 2010-05-28 1:00 PM, Phil Howard wrote:
Have you seen any config check tools?
Yes - it's called a brain. ;)
I think you are missing the point.
Not...
A config check tool would be sifting through the details of the main.cf file, and the postconf-n.out file, and reporting the difference between what one thinks they have configured and what Postfix understands the configuration to be.
??? Again, that's what your *brain* is for. There is no program capable of reading one's mind, or ascertaining details of your environment and/or system requirements.
Seriously - only you know your environment well enough to evaluate any given config.
I think you are missing the point.
Not...
Since what Postfix uses as the configuration isn't guaranteed to be what is coded ...
Sure it is...
because config items do get changed by subsequent config items ...
??? Not sure what you mean by that. If the same setting is defined multiple times in main.cf, the last one wins. That is well documented.
a tool that can compare things comes in valuable.
It depends, but yes, some brains are valuable.
We all know that doing things in less time is a good thing (or else there would be not complaint about wasting time). But manually sifting through two files, point by point, and cross checking everything, every time, is as much, or more, of a time waster.
What 2 files? I thought we were talking about ,ain.cf/postconf -n output?
And given that it would be done quite often, one is wasting a lot of time if they carry out that process. This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf),
That describes postconf to a 't'... :)
and just produce the warnings ... "hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that".
Nope... it is enough to know that if a setting is defined twice, the last one wins. If you define a setting, and postconf -n output doesn't show what you expect, then the very first thing to do is grep main/cf for that term to see if it in there more than once. The second thing to do is make sure you're editing the right main.cf file.
Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output.
But it doesn't complain for conflict errors. And that was the class of error that happened.
It isn't *supposed* to complain - the *documented* behavior is that the last value wins.
This in fact makes customizing settings easy (at least for me). I just put all of my settings at the end of the file, so I know that those will be the ones used regardless of what is specified above.
--
Best regards,
Charles
On Fri, 28 May 2010 16:26:53 -0400 Charles Marcus <CMarcus@Media-Brokers.com> articulated:
This in fact makes customizing settings easy (at least for me). I just put all of my settings at the end of the file, so I know that those will be the ones used regardless of what is specified above.
That is exactly how I do mine also. If I ever needed to revert to a virgin config file, all I need do is either comment out or delete all of the entries I added. I have always considered Postfix's "Last Wins" philosophy in its config file a big +.
-- Jerry Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
No matter how subtle the wizard, a knife in the shoulder blades will seriously cramp his style.
On 2010-05-28 11:25 AM, Phil Howard wrote:
On Fri, May 28, 2010 at 09:55, Charles Marcus wrote:
On 2010-05-27 1:42 PM, Phil Howard wrote:
Yup, there was a 2nd setting nearly at the bottom of the file, and it was different. Thanks for catching that.
This is why you *always* go by what output pof postconf -n says, not what you think you put in main.cf.
You wasted a lot of time (yours and others here) on that unnecessarily...
My main.cf file has the comments (my own that explains why settings are there, not the default comments). It is the easier to read file.
Yes, but you are missing the point - the output of postconf -n shows *exactly* what postfix is *using*, *not* what you *think* it is using because you *misread* (ie, missed the last recipient_delimiter entry that was different from the one you were changing).
It can also demonstrate that you aren't using the main.cf (or dovecot.conf) file that you thought you were using due to running something chroot'd when you didn't realize it, or packaging errors by your package maintainer, etc, etc, etc...
Even then, I was also reading the postconf -n output and just didn't see the subtle difference (I was thinking more along the lines of "what else is needed").
Right - you weren't using the output as intended.
--
Best regards,
Charles
On Wed, May 26, 2010 at 16:59, Jerry <dovecot.user@seibercom.net> wrote:
On or about line 821 in the Dovecot.conf file:
#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
If you have not all ready done so, add the "+" to the end of the list and un-comment the line. I believe you will have to restart 'dovecot' for the change to take affect.
Now added.
By the way, Postfix must be properly configured to pass the email address to dovecot. I leave that as an exercise to the user. You might want to start here thought:
The question I have next is, what is "properly". Should Postfix pass "phil+howard@example.com" or "phil@example.com" ... and in which place (on the command line to deliver? ... the first line passed through the pipe? ... in the RFC822 To: header?).
How does Dovecot know I have "recipient_delimiter = +" (vs. "recipient_delimiter = -" or such) in main.cf, or should it matter? It would seem to me that if Dovecot has to figure out that "phil+howard@example.com" goes into the mailbox for "phil@example.com" then it needs to know that + is the character being used for that. Otherwise it seems that Postfix should tell it that the delivery is to "phil@example.com".
One frequent confuse I see in referencing documentation for a problem, is understanding what it is that needs to be achieved, in order for the proper documented configuration to be determined.
On Wed, May 26, 2010 at 16:59, Jerry <dovecot.user@seibercom.net> wrote:
On or about line 821 in the Dovecot.conf file:
Actually, a lot earlier in my trimmed down version :-)
#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
If you have not all ready done so, add the "+" to the end of the list and un-comment the line. I believe you will have to restart 'dovecot' for the change to take affect.
This alone made it work. Thanks! Given Gregory Finch's response, I'll have to guess that the default included + or something else is going on. I did have auth_username_chars uncommented (so I was not using the default) and without the + earlier.
On Thu, May 27, 2010 at 11:34, Phil Howard <ttiphil@gmail.com> wrote:
On Wed, May 26, 2010 at 16:59, Jerry <dovecot.user@seibercom.net> wrote:
On or about line 821 in the Dovecot.conf file:
Actually, a lot earlier in my trimmed down version :-)
#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
If you have not all ready done so, add the "+" to the end of the list and un-comment the line. I believe you will have to restart 'dovecot' for the change to take affect.
This alone made it work. Thanks! Given Gregory Finch's response, I'll have to guess that the default included + or something else is going on. I did have auth_username_chars uncommented (so I was not using the default) and without the + earlier.
I spoke too quick. It seems to be intermittent.
May 27 11:00:02 eth0 postfix/pipe[25377]: DCA7868417: to=<phil+howard@example.com>, relay=dovecot, delay=0.27, delays=0.21/0.01/0/0.05, dsn=4.1.1, status=SOFTBOUNCE (user unknown) May 27 11:04:27 eth0 postfix/pipe[25411]: 16DD168411: to=<phil+howard@example.com>, relay=dovecot, delay=397, delays=397/0.01/0/0.04, dsn=4.1.1, status=SOFTBOUNCE (user unknown) May 27 11:04:27 eth0 postfix/pipe[25413]: 864CB6846F: to=<phil+howard@example.com>, relay=dovecot, delay=67732, delays=67732/0.01/0/0.05, dsn=4.1.1, status=SOFTBOUNCE (user unknown) May 27 11:09:09 eth0 postfix/pipe[25605]: DCA7868417: to=<phil+howard@example.com>, relay=dovecot, delay=547, delays=547/0.01/0/0.08, dsn=2.0.0, status=sent (delivered via dovecot service) May 27 11:14:08 eth0 postfix/pipe[25682]: 16DD168411: to=<phil+howard@example.com>, relay=dovecot, delay=978, delays=977/0.01/0/0.09, dsn=2.0.0, status=sent (delivered via dovecot service) May 27 11:46:11 eth0 postfix/pipe[26384]: DEC3368411: to=<phil+howard@example.com>, relay=dovecot, delay=13, delays=13/0/0/0.04, dsn=4.1.1, status=SOFTBOUNCE (user unknown) May 27 11:46:54 eth0 postfix/pipe[26384]: DA42468412: to=<phil+howard@example.com>, relay=dovecot, delay=13, delays=13/0/0/0.04, dsn=4.1.1, status=SOFTBOUNCE (user unknown) May 27 11:47:37 eth0 postfix/pipe[26384]: E612968413: to=<phil+howard@example.com>, relay=dovecot, delay=13, delays=13/0/0/0.03, dsn=4.1.1, status=SOFTBOUNCE (user unknown)
On Wed, May 26, 2010 at 16:59, Jerry <dovecot.user@seibercom.net> wrote:
By the way, Postfix must be properly configured to pass the email address to dovecot. I leave that as an exercise to the user. You might want to start here thought:
I already have this:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop}
Maybe /usr/lib/dovecot/deliver is just the path the Ubuntu package team chose for Dovecot?
The intent is to deliver into the mailbox INBOX for the user without the extension, but with the extension still in there where user scripts can see it and choose to act on it. I don't want an explosion of folders in the event of a DoS attack via massively randomly generated extensions.
So the big question is, is Postfix supposed to split at + and pass user instead of user+ext to the transport program, or is dovecot/deliver supposed to split at + and and use that for %n ? If I knew what was SUPPOSED to happen, it would be easier to make use of understanding some of the logic to make it happen.
It's one thing to know what something MEANS. It's entirely different to know what something DOES. I think the latter is more meaningful, but it also depends highly on knowing that aspect of everything.
participants (4)
-
Charles Marcus
-
Gregory Finch
-
Jerry
-
Phil Howard