Re: Strange Bounce
On 4/24/2009, Vince Sabio (vi...@vjs.org) wrote: I'd rather not post information like that _pro forma_; if there's some subset of that information that might be of help in diagnosing this issue, then I'd be happy to post it. I realize that my reluctance to post the entire data set might limit the likelihood of getting to the bottom of this error. It will not just limit it, it will probably cause most everyone to totally ignire you. Oh... and its also extraordinarily silly... what exactly do you think you are protecting by refusing to post it? -- Best regards, Charles
private/anvil errors
Still working on getting postfix and dovecot playing nice, current issue I am trying to understand and solve is this error: Apr 24 02:14:58 catalyst postfix/smtpd[358]: private/anvil: wanted attribute: status I have 123 log lines of that, they vary somewhat: wanted attribute: count wanted attribute: rate wanted attribute: (list terminator) wanted attribute: status Those seem to be the bulk of the log lines. What is this error in regards to, and any ideas on how to solve it? This is a PPC Dual 2.0Ghz machine, running Mac OS X 10.5 $postconf -n alias_maps = hash:/opt/local/etc/postfix/aliases biff = no broken_sasl_auth_clients = yes command_directory = /opt/local/sbin config_directory = /opt/local/etc/postfix daemon_directory = /opt/local/libexec/postfix data_directory = /opt/local/var/lib/postfix debug_peer_level = 2 debug_peer_list = 127.0.0.1 default_privs = nobody disable_vrfy_command = yes html_directory = no inet_interfaces = all invalid_hostname_reject_code = 450 mail_owner = _postfix mailq_path = /opt/local/bin/mailq manpage_directory = /opt/local/share/man maps_rbl_reject_code = 450 message_size_limit = 0 mydestination = localhost myhostname = catalyst.hostwizard.com mynetworks = 64.84.37.0/26 newaliases_path = /opt/local/bin/newaliases non_fqdn_reject_code = 450 queue_directory = /opt/local/var/spool/postfix readme_directory = /opt/local/share/postfix/readme sample_directory = /opt/local/share/postfix/sample sendmail_path = /opt/local/sbin/sendmail setgid_group = _postdrop smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem smtp_tls_security_level = may smtp_tls_session_cache_database = btree:$data_directory/ smtp_tls_session_cache smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce,permit smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticatedreject_unauth_destinationpermit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_exceptions_networks = $mynetworks smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_ask_ccert = yes smtpd_tls_cert_file = /opt/local/etc/ssl/certs/postfix.pem smtpd_tls_key_file = /opt/local/etc/ssl/private/postfix.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:$data_directory/ smtpd_tls_session_cache tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 virtual_alias_maps = mysql:/opt/local/etc/postfix/mysql-virtual-alias- maps.cf,mysql:/opt/local/etc/postfix/mysql-email2email.cf virtual_gid_maps = static:5000 virtual_mailbox_base = /opt/local/var/vmail virtual_mailbox_domains = mysql:/opt/local/etc/postfix/mysql-virtual- mailbox-domains.cf virtual_mailbox_maps = mysql:/opt/local/etc/postfix/mysql-virtual- mailbox-maps.cf virtual_minimum_uid = static:5000 virtual_transport = dovecot virtual_uid_maps = static:5000 -- Scott * If you contact me off list replace talklists@ with scott@ *
Re: shellscript as policy-service -- zombie/load
Andre H?bner: Hello, for testing purposes i wrote a policy-service for postfix as a shellscript. My Script is working very well, iam happy with its functionality ;) But unfortunately there is one problem when a lot of mails are incoming. the shellscript just does some grepping in small files etc. and is giving back a allowd result.. My Shellscript is spawned from master.cf like this: policy-mycheck unix - n n - - spawn user=nobody argv=nice -n 15 /usr/lib/postfix/mycheckscript.sh When a lot of mails are incoming i got a high number of zombies. as a consequence of this my system load gets really high. Are there some general methods to avoid this? Find out what is the parent process of the zombies. This parent process is not cleaning up as it should. Wietse
Re: private/anvil errors
Scott Haneda: Those seem to be the bulk of the log lines. What is this error in regards to, and any ideas on how to solve it? Don't turn on VERBOSE LOGGING. Ahh, thanks. In the log, how does one tell the difference between notice, error, and normal messages? To me, that appeared as a bad thing, I had no idea it was just informational. Don't turn on verbose logging unless asked to do so. It was the only way I could solve some other issues I was having. It was helpful for me to be able to pin down errors that were being shown in a non verbose case. I could not have figured out what was happening were it not for verbose logging. Errors are ALWAYS logged in NON-VERBOSE mode. Wietse
Re: Postfix get_service_attr, dovecot, mysql, OS X
Scott Haneda: Apr 23 16:28:02 postfix/pipe[49289]: fatal: get_service_attr: unknown username: vmail This error is logged in non-verbose mode. In master.cf you have pipe ... user=vmail. Either there is no such user in the password database, or you have incorrect access permissions so that an unprivileged postfix process cannot access the password database. This error happens entirely before Postfix executes any Dovecot software, and therefore logfile permissions are a red herring. Wietse
Re: Max Size Not Working Correctly?
On Thu, Apr 23, 2009 at 11:35 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: There you are message delivered to procmail, and procmail returned a success (0) exit code. What happened after procmail is outside the scope of Postfix. Ok, fair enough but can procmail issue the mesage too big response that the sending Exim server received? Wouldn't Postfix have had to send that?
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/24/2009 07:58 AM: I am a little confused about main.cf and master.cf. Is there overlap in some of the settings? Do some settings exist in both files, or at least are interchangable? If this is the case, under what conditions do you decide to do so? From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer to other parameters as $name etc., just like in main.cf. See postconf(5) for syntax. As implied, it's useful when you need to override the settings in main.cf to get different behaviour appropriate to the service you're setting up in master.cf (submission, reinjection from proxy/filter, etc.). I successfully sent emails through this system as unauthenticated, authenticated, with tls, and with ssl. This is a migration, and I would like to have minimal email client settings needing change. My old server did not have SSL or TLS. Old Server: No SSL, No TLS port 25 = normal inbound, plus smtp auth'd users port 587 = forced auth'd users I am willing to disallow user connection to port 25. How do I do this? In main.cf or master.cf? Right now, I believe I only have this: [snip... master.cf ] smtp inet n - n - - smtpd I believe I need to add a restriction in there to stop clients from connecting? There was a recent thread on this subject, worth reading: http://www.mail-archive.com/postfix-users@postfix.org/msg06230.html For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. I can not seem to get this to work, it is either no encryption, or forced encryption. [snip... master.cf ] submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated -o milter_macro_daemon_name=ORIGINATING Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous * Do I even need the milter line? Good question. It may depend on whether or not you use milters. I don't, but I leave it in because I don't want issues later if I decide to deploy a milter. Port 465, I believe will be reserved exclusively for SSL? Port 587 does the TLS, is that correct? Or is the SSL just wrapping around the TLS? [snip... master.cf ] 465 inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING This is for legacy support. I suggest you don't activate it until you're sure you need it. Wrapper mode is different from offering STARTTLS. Nearly all modern clients support STARTTLS. If someone absolutely needs port 465, that could be a red flag that the user needs an upgrade. However, some webmail programs might have poor support for STARTTLS, forcing you to enable smtps if you require an encrypted connection. In Apple Mail, there are auth options of ntlm, md5 Challenge-Reponse, Kerberos, and Password. In Thunderbird I notices there are no such options. Which are used in Thunderbird? What is the best to use, or is it only applicable if you are choosing to not use SSL/TLS? Thunderbird has a Use secure authentication checkbox that supports multiple mechanisms (independent of SSL/TLS). Unfortunately, *it* decides which one to use, which I find very frustrating. I'm happy for mail clients to select the best mechanisms available for easy autoconfiguration, but it would be nice to have the ability to set them explicitly (for troubleshooting or security reasons). In any case, it's good practice to check this box if the server supports secure mechanisms, for a little extra protection beyond SSL/TLS. I have been pretty up and down the docs, this is somehow not making a lot of sense. I think once I understand what crosses over in config from main.cf and master.cf, it will make more sense. postconf -n smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem If you're not using client certificate authentication (and you probably aren't), delete those lines. smtp_tls_security_level = may This is good. smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticatedreject_unauth_destinationpermit You can remove permit_sasl_authenticated from here if you don't want to offer authenticated submission on port 25... smtpd_sasl_auth_enable = yes ...and change this to no (or remove the line,
Re: Max Size Not Working Correctly?
Rick Duval: On Thu, Apr 23, 2009 at 11:35 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: There you are message delivered to procmail, and procmail returned a success (0) exit code. What happened after procmail is outside the scope of Postfix. Ok, fair enough but can procmail issue the mesage too big response that the sending Exim server received? Wouldn't Postfix have had to send that? By exiting with status 0, procmail tells Postfix that delivery was successful. Therefore, Postfix will not report errors to the sender. Wietse
Re: Masquerade issue
Victor Duchovni wrote: On Fri, Apr 17, 2009 at 09:22:00AM -0400, Shelley Waltz wrote: # postconf -n masquerade_domains = !master2.cabm.rutgers.edu !raven.cabm.rutgers.edu !heron.cabm.rutgers.edu cabm.rutgers.edu This looks OK, show unedited (consistent localpart mangling is OK, if you mangle consistently, DO NOT modify the domainpart) logging for a message that did not get masqueraded, and the envelope and headers as sent and as received. You never did mention which hostname failed to be masqueraded. mydestination = $myhostname, localhost.$mydomain, nmrlab.$mydomain, $mydomain mydomain = cabm.rutgers.edu myhostname = roadrunner.cabm.rutgers.edu mynetworks = 192.76.178.0/24 128.6.56.128/25 127.0.0.0/8 myorigin = $mydomain This should be sufficient to masquerade the hosts under cabm.rutgers.edu that not (in or) the exception sub-domains. (mail for puma.cabm.rutgers.edu loops back to myself) (mail for buena.cabm.rutgers.edu loops back to myself) (mail for falcon.cabm.rutgers.edu loops back to myself) (mail for rhino.cabm.rutgers.edu loops back to myself) This is not unedited logging. Show all logging for the queue-ids in question. messages in maillog look like this ... Apr 12 05:25:21 roadrunner postfix/smtp[10809]: B7D9311D8008: to=r...@buena.cabm.rutgers.edu, relay=none, delay=43453, delays=43453/0.01/0/0, dsn=4.4.6, status=SOFTBOUNCE (mail for buena.cabm.rutgers.edu loops back to myself) I am still unclear on resolving this issue. As I mentioned, my previous postfix with the same configuration allowed all hosts on my single(no virtual)domain configuration to be masqueraded. This was true for all hosts except those specified in masquerade_domains with the ! negation. I want to do exactly this for the new server, but mail to u...@hostmane.domain.edu does not masquerade and receives the loops back to myself error. It is perplexing that such a simple issue cannot have a simple resolution, or did something change between postfix--2.0.18 and postfix-2.3.3?
Re: Forwarded bounce messages coming from MAILER-DAEMON
David Jonas wrote: When a bounce message from is going to an address that is in virtual_alias_maps the sender gets rewritten to MAILER-DAEMON, or at least that is what seems to happen. Some mail servers reject MAILER-DAEMON as a sender due to the lack of domain (att.net, comcast.net). You'll need to show evidence so everyone knows what you're referring to. How can I control this? What is the proper thing to do in this case? Show logging demonstrating the problem, and postconf -n output. I can't seem to figure this out. I tried setting empty_address_recipient = mailer-dae...@$myhostname, but that had no noticeable effect. ... as expected. http://www.postfix.org/postconf.5.html#empty_address_recipient -- Noel Jones
Re: Strange Bounce
Charles Marcus wrote (on Fri, Apr 24, 2009 at 05:51:51AM -0400): On 4/24/2009, Vince Sabio (vi...@vjs.org) wrote: I'd rather not post information like that _pro forma_; if there's some subset of that information that might be of help in diagnosing this issue, then I'd be happy to post it. I realize that my reluctance to post the entire data set might limit the likelihood of getting to the bottom of this error. It will not just limit it, it will probably cause most everyone to totally ignire you. Oh... and its also extraordinarily silly... what exactly do you think you are protecting by refusing to post it? Perhaps his reluctance stems not from disclosing it, but from having it sit in archives forever, waiting to be scraped. With that in mind, would the denizens of this list mind posters supplying links to the necessary info, said links to vanish when the thread is over? That's what I'd like to do.
Re: Forwarded bounce messages coming from MAILER-DAEMON
On Thu, Apr 23, 2009 at 05:15:52PM -0700, David Jonas wrote:
When a bounce message from is going to an address that is in
virtual_alias_maps the sender gets rewritten to MAILER-DAEMON, or at
least that is what seems to happen. Some mail servers reject MAILER-DAEMON
as a sender due to the lack of domain (att.net, comcast.net). How can I
control this? What is the proper thing to do in this case?
The pipe(8) daemon by default passes MAILER-DAEMON as ${sender} in place
of the empty address. If your argv setting is robust, you can ask it
to not do that. Usually, pipe(8) leads to final delivery and the envelope
sender is not significant. If you are using pipe(8) content filters, set
it up to not break the envelope.
Also Postfix does not send unqualified addresses to remote servers unless
you turn off append_at_myorigin, which you should never do.
--
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: Masquerade issue
On Fri, Apr 24, 2009 at 10:22:32AM -0400, Shelley Waltz wrote: Apr 12 05:25:21 roadrunner postfix/smtp[10809]: B7D9311D8008: to=r...@buena.cabm.rutgers.edu, relay=none, delay=43453, delays=43453/0.01/0/0, dsn=4.4.6, status=SOFTBOUNCE (mail for buena.cabm.rutgers.edu loops back to myself) I am still unclear on resolving this issue. As I mentioned, my previous postfix with the same configuration allowed all hosts on my single(no virtual)domain configuration to be masqueraded. No version of Postfix has ever masqueraded envelope recipients by default. This was true for all hosts except those specified in masquerade_domains with the ! negation. The solution is to correctly rewrite the envelope recipient on the null client machines, for which I strongly recommend setting myorigin correctly, and not using masquerading at all! http://www.postfix.org/MULTI_INSTANCE_README.html#quick I want to do exactly this for the new server, but mail to u...@hostmane.domain.edu does not masquerade and receives the loops back to myself error. It is perplexing that such a simple issue cannot have a simple resolution, or did something change between postfix--2.0.18 and postfix-2.3.3? Nothing changed in Postfix, you have changed something on your side. -- 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: Forwarded bounce messages coming from MAILER-DAEMON
David Jonas:
When a bounce message from is going to an address that is in
virtual_alias_maps the sender gets rewritten to MAILER-DAEMON, or at
least that is what seems to happen. Some mail servers reject
MAILER-DAEMON as a sender due to the lack of domain (att.net,
comcast.net). How can I control this? What is the proper thing to do in
this case?
If you use the simple content filter approach as described in
http://www.postfix.org/FILTER_README.html with Postfix 2.3 and
later, use:
/etc/postfix/master.cf:
filterunix - n n - 10 pipe
null_sender=
flags=Rq user=filter argv=/path/to/script -f ${sender} -- ${recipient}
This prevents the null sender from being replaced.
Wietse
Re: Forwarded bounce messages coming from MAILER-DAEMON
Victor Duchovni:
On Thu, Apr 23, 2009 at 05:15:52PM -0700, David Jonas wrote:
When a bounce message from is going to an address that is in
virtual_alias_maps the sender gets rewritten to MAILER-DAEMON, or at
least that is what seems to happen. Some mail servers reject MAILER-DAEMON
as a sender due to the lack of domain (att.net, comcast.net). How can I
control this? What is the proper thing to do in this case?
The pipe(8) daemon by default passes MAILER-DAEMON as ${sender} in place
of the empty address. If your argv setting is robust, you can ask it
to not do that. Usually, pipe(8) leads to final delivery and the envelope
sender is not significant. If you are using pipe(8) content filters, set
it up to not break the envelope.
Also Postfix does not send unqualified addresses to remote servers unless
you turn off append_at_myorigin, which you should never do.
As of Postfix 2.3, filtered mail is re-injected with sendmail -G
to prevent signature damage due to address rewriting. Thus,
MAILER-DAEMON is no longer qualified as it used to be.
I'll update the FILTER_README document.
Wietse
Re: Strange problem with postfix and dovecot sasl auth
Hello, I've been trying to setup postfix with tls and smtp auth (dovecot sasl). I'm now stuck with the smtp auth part, with a strange error. For a few days I've tried to search information about similar problems, but found none. Now I'm hoping somebody here could help me out. I'm running Ubuntu Jaunty on AMD64. I've disabled tls (and a lot of other options, and not running in a chroot jail) for now. The problem is, that as soon as I enable smtp auth in postfix (smtpd_sasl_auth_enable), smtp stops working. When doing bash:# telnet localhost 25 Trying ::1... ^ I'm guessing that something in the mix isn't properly configured for IPv6. I's probably configurable, but unless you really need IPv6, I'd suggest just disabling IPv6 in your network stack, commenting out any IPv6 references in Postfix and trying again. Terry
Strange problem with postfix and dovecot sasl auth
Hello,
I've been trying to setup postfix with tls and smtp auth (dovecot sasl).
I'm now stuck with the smtp auth part, with a strange error. For a few
days I've tried to search information about similar problems, but found
none. Now I'm hoping somebody here could help me out. I'm running Ubuntu
Jaunty on AMD64.
I've disabled tls (and a lot of other options, and not running in a
chroot jail) for now. The problem is, that as soon as I enable smtp auth
in postfix (smtpd_sasl_auth_enable), smtp stops working. When doing
bash:# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
...and it halts, and timeouts. Never prints the banner. I've get
increased logging enabled ('smtpd -vv' in master.cf) and below is the
relevant part, with the 'no SASL authentication mechanisms' print:
Apr 24 15:42:30 server postfix/smtpd[8126]: xsasl_dovecot_server_create:
SASL service=smtp, realm=(null)
Apr 24 15:42:30 server postfix/smtpd[8126]: name_mask: noanonymous
Apr 24 15:42:30 server postfix/smtpd[8126]:
xsasl_dovecot_server_connect: Connecting
Apr 24 15:42:40 server postfix/smtpd[8126]:
xsasl_dovecot_server_connect: auth reply: status
Apr 24 15:42:50 server postfix/smtpd[8126]: fatal: no SASL
authentication mechanisms
Apr 24 15:42:50 server postfix/pipe[8128]: warning: unexpected
end-of-input from dovecot socket while reading input attribute name
Apr 24 15:42:50 server postfix/pipe[8128]: warning: deliver_request_get:
error receiving common attributes
Apr 24 15:42:51 server postfix/master[8903]: warning: process
/usr/lib/postfix/smtpd pid 8126 exit status 1
I've seen the 'no SASL authentication mechanisms' erros with google, but
usually because postfix is unable to find the dovecot client auth
socket. I don't think this is my problem. Below are output of 'postconf
-n' and 'dovecot -n' commands:
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
canonical_maps = hash:/etc/postfix/canonical
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = all
mailbox_command = /usr/lib/dovecot/deliver -c
/etc/dovecot/dovecot-postfix.conf -n -m ${EXTENSION}
mydestination =
mydomain = *my.domain*
myhostname = *server.at.my.domain*
mynetworks = 127.0.0.0/8, 192.168.0.0/24, [::1]/128
myorigin = /etc/mailname
readme_directory = no
relay_domains =
relayhost = [*my.isp.provider*]
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/dovecot
smtpd_sasl_type = dovecot
strict_rfc821_envelopes = yes
virtual_gid_maps = static:5000
virtual_mailbox_domains = /etc/postfix/vhosts
virtual_minimum_uid = 1000
virtual_transport = dovecot
virtual_uid_maps = static:5000
# 1.1.11: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.28-11-server x86_64 Ubuntu 9.04 ext3
base_dir: /var/run/dovecot/
log_path: /var/log/dovecot.log
info_log_path: /var/log/dovecot-info.log
ssl_cert_file: /etc/ssl/certs/dovecot.pem
ssl_key_file: /etc/ssl/private/dovecot.pem
disable_plaintext_auth: no
login_dir: /var/run/dovecot//login
login_executable: /usr/lib/dovecot/imap-login
valid_chroot_dirs: /var/spool/vmail
mail_location: maildir:/home/vmail/%d/%n/Maildir
auth default:
mechanisms: plain login
debug: yes
passdb:
driver: passwd-file
args: /etc/dovecot/passwd
userdb:
driver: static
args: uid=vmail gid=vmail home=/home/vmail/%d/%n
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 438
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 384
user: vmail
I can see the private/auth socket created when dovecot starts, with
postfix:postfix permissions. Also, netstat shows it:
bash:# netstat -ln | grep dovecot
unix 2 [ ACC ] STREAM LISTENING 111791 private/dovecot
unix 2 [ ACC ] STREAM LISTENING 120787
/var/run/dovecot//dict-server
unix 2 [ ACC ] STREAM LISTENING 120789
/var/run/dovecot//login/default
unix 2 [ ACC ] STREAM LISTENING 120800
/var/run/dovecot/auth-master
unix 2 [ ACC ] STREAM LISTENING 120803
/var/run/dovecot//auth-worker.29982
I'm totally clueless as to what to try next. Does anybody here have any
suggestions how to continue, what to try or debug. I'd bee very greatful
for any ideas.
TIA,
Juha Pahkala
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Strange problem with postfix and dovecot sasl auth
Juha Pahkala: Apr 24 15:42:30 server postfix/smtpd[8126]: name_mask: noanonymous Apr 24 15:42:30 server postfix/smtpd[8126]: xsasl_dovecot_server_connect: Connecting Apr 24 15:42:40 server postfix/smtpd[8126]: xsasl_dovecot_server_connect: auth reply: status Apr 24 15:42:50 server postfix/smtpd[8126]: fatal: no SASL authentication mechanisms Your DOVECOT configuration provides no authentication mechanisms that are allowed by POSTFIX smtpd_sasl_security_options. Wietse
Re: Turning of milter checks
On Fri, Apr 24, 2009 at 6:48 AM, Wietse Venema wie...@porcupine.org wrote: FYI, The header_checks parameter does not control whether or not Milter operation is invoked, so your observations are incorrect. If you want to pursue this further, show a telnet mail submission and the corresponding logging. Also, instead of it does work and it does not work please describe what happens and what you expected to happen. Wietse Well, today the milter checks are not happening, which is correct. It doesn't make any sense to me. My best guess is there was a typo somewhere, though I checked that and did not find one. I'm sorry for wasting your time, I thought I tried everything (twice) before posting. The ps/pgrep output is still perplexing. If I have just -o receive_override_options=no_milters the pgrep output is: 92212 smtpd -n 2525 -t inet -u -o stress= -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= 127.0.0.0/8,xx.yy.zz.0/24 If I have -o receive_override_options=no_header_body_checks,no_milters pgrep output is: 91904 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks
Re: Turning of milter checks
Dan Lists: The ps/pgrep output is still perplexing. If I have just -o receive_override_options=no_milters the pgrep output is: 92212 smtpd -n 2525 -t inet -u -o stress= -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= 127.0.0.0/8,xx.yy.zz.0/24 This information is taken from in the kernel address space. If I have -o receive_override_options=no_header_body_checks,no_milters pgrep output is: 91904 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks This information is taken from the process address space. While parsing -o name=value, smtpd will split the name=value by overwriting the = with a null byte (which is used as string terminator). Therefore, the output above only shows -o name. Why one command takes the information from the kernel, and the other from the process, is a question that your vendor can answer. Wietse
Re: SMTPD segfaults on startup
Wietse Venema wrote (on Fri, Apr 24, 2009 at 02:28:12PM -0400): N. Yaakov Ziskind: Uh-oh. Just upgraded a Ubuntu box to the latest and greatesti (jaunty jackelope), and postfix is dying all over the place: Apr 24 14:06:25 chocolate postfix/smtpd[5176]: connect from unknown[unknown] Apr 24 14:06:25 chocolate postfix/smtpd[5176]: lost connection after CONNECT from unknown[unknown] Apr 24 14:06:25 chocolate postfix/smtpd[5176]: disconnect from unknown[unknown] Apr 24 14:06:25 chocolate kernel: [ 1895.725677] smtpd[5176]: segfault at b0d12950 eip b7c560b0 esp bfd1241c error 6 Apr 24 14:06:25 chocolate postfix/master[5141]: warning: process /usr/lib/postfix/smtpd pid 5176 killed by signal 11 Apr 24 14:06:25 chocolate postfix/master[5141]: warning: /usr/lib/postfix/smtpd:bad command startup -- throttling and on and on. How in the heck did I manage to shoot myself in the foot? DLL hell. Typical causes are: - Mixing different versions of Berkeley DB, OpenSSL, SASL, etc. For example, Postfix was built with version X, but nsswitch.conf functions are built with version Y. An investigation with ldd usually shows what the discrepancy is. Wietse Oh? I don't know what I'm looking at: # ldd smtpd linux-gate.so.1 = (0xb7f3e000) libpostfix-master.so.1 = /usr/lib/libpostfix-master.so.1 (0xb7f2f000) libpostfix-tls.so.1 = /usr/lib/libpostfix-tls.so.1 (0xb7f2) libpostfix-dns.so.1 = /usr/lib/libpostfix-dns.so.1 (0xb7f19000) libpostfix-global.so.1 = /usr/lib/libpostfix-global.so.1 (0xb7ee9000) libpostfix-util.so.1 = /usr/lib/libpostfix-util.so.1 (0xb7ebc000) libssl.so.0.9.8 = /lib/i686/cmov/libssl.so.0.9.8 (0xb7e76000) libcrypto.so.0.9.8 = /lib/i686/cmov/libcrypto.so.0.9.8 (0xb7d2a000) libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0xb7d11000) libdb-4.6.so = /usr/lib/libdb-4.6.so (0xb7be2000) libnsl.so.1 = /lib/tls/i686/cmov/libnsl.so.1 (0xb7bc9000) libresolv.so.2 = /lib/tls/i686/cmov/libresolv.so.2 (0xb7bb3000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7a5) libdb-4.7.so = /usr/lib/libdb-4.7.so (0xb78fb000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xb78f7000) libz.so.1 = /lib/libz.so.1 (0xb78e1000) libpthread.so.0 = /lib/tls/i686/cmov/libpthread.so.0 (0xb78c8000) /lib/ld-linux.so.2 (0xb7f3f000) This box is stock ubuntu, and i only use ssl, postfix and samba, so i'm wondering what i did wrong. i'm not using sasl, tls or anything other than postgrey added on. should i just remove postfix and re-install? is it safe to keep main.cf and the files i created/modified (transport, recipient_checks, whitelist, helo_access, aliases and virtual)? Thanks!
Re: SMTPD segfaults on startup
N. Yaakov Ziskind wrote (on Fri, Apr 24, 2009 at 02:37:36PM -0400): Wietse Venema wrote (on Fri, Apr 24, 2009 at 02:28:12PM -0400): N. Yaakov Ziskind: Uh-oh. Just upgraded a Ubuntu box to the latest and greatesti (jaunty jackelope), and postfix is dying all over the place: Apr 24 14:06:25 chocolate postfix/smtpd[5176]: connect from unknown[unknown] Apr 24 14:06:25 chocolate postfix/smtpd[5176]: lost connection after CONNECT from unknown[unknown] Apr 24 14:06:25 chocolate postfix/smtpd[5176]: disconnect from unknown[unknown] Apr 24 14:06:25 chocolate kernel: [ 1895.725677] smtpd[5176]: segfault at b0d12950 eip b7c560b0 esp bfd1241c error 6 Apr 24 14:06:25 chocolate postfix/master[5141]: warning: process /usr/lib/postfix/smtpd pid 5176 killed by signal 11 Apr 24 14:06:25 chocolate postfix/master[5141]: warning: /usr/lib/postfix/smtpd:bad command startup -- throttling and on and on. How in the heck did I manage to shoot myself in the foot? DLL hell. Typical causes are: - Mixing different versions of Berkeley DB, OpenSSL, SASL, etc. For example, Postfix was built with version X, but nsswitch.conf functions are built with version Y. An investigation with ldd usually shows what the discrepancy is. Wietse Oh? I don't know what I'm looking at: # ldd smtpd linux-gate.so.1 = (0xb7f3e000) libpostfix-master.so.1 = /usr/lib/libpostfix-master.so.1 (0xb7f2f000) libpostfix-tls.so.1 = /usr/lib/libpostfix-tls.so.1 (0xb7f2) libpostfix-dns.so.1 = /usr/lib/libpostfix-dns.so.1 (0xb7f19000) libpostfix-global.so.1 = /usr/lib/libpostfix-global.so.1 (0xb7ee9000) libpostfix-util.so.1 = /usr/lib/libpostfix-util.so.1 (0xb7ebc000) libssl.so.0.9.8 = /lib/i686/cmov/libssl.so.0.9.8 (0xb7e76000) libcrypto.so.0.9.8 = /lib/i686/cmov/libcrypto.so.0.9.8 (0xb7d2a000) libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0xb7d11000) libdb-4.6.so = /usr/lib/libdb-4.6.so (0xb7be2000) libnsl.so.1 = /lib/tls/i686/cmov/libnsl.so.1 (0xb7bc9000) libresolv.so.2 = /lib/tls/i686/cmov/libresolv.so.2 (0xb7bb3000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7a5) libdb-4.7.so = /usr/lib/libdb-4.7.so (0xb78fb000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xb78f7000) libz.so.1 = /lib/libz.so.1 (0xb78e1000) libpthread.so.0 = /lib/tls/i686/cmov/libpthread.so.0 (0xb78c8000) /lib/ld-linux.so.2 (0xb7f3f000) This box is stock ubuntu, and i only use ssl, postfix and samba, so i'm wondering what i did wrong. i'm not using sasl, tls or anything other than postgrey added on. should i just remove postfix and re-install? is it safe to keep main.cf and the files i created/modified (transport, recipient_checks, whitelist, helo_access, aliases and virtual)? Thanks! To answer my own question: apt-get remove postfix ; apt-get install postfix got things running again. Thanks to all who looked at this.
Re: private/anvil errors
On Apr 24, 2009, at 6:15 AM, Wietse Venema wrote: Scott Haneda: Those seem to be the bulk of the log lines. What is this error in regards to, and any ideas on how to solve it? Don't turn on VERBOSE LOGGING. Ahh, thanks. In the log, how does one tell the difference between notice, error, and normal messages? To me, that appeared as a bad thing, I had no idea it was just informational. Don't turn on verbose logging unless asked to do so. It was the only way I could solve some other issues I was having. It was helpful for me to be able to pin down errors that were being shown in a non verbose case. I could not have figured out what was happening were it not for verbose logging. Errors are ALWAYS logged in NON-VERBOSE mode. Good to know, thanks. It was not clear to me, and some post I read suggested to turn it on. I have commented it out now, and the logs are clean, thanks for the help. -- Scott * If you contact me off list replace talklists@ with scott@ *
Re: Suggestions on submission port config
Thanks for this, this is getting me on track, comments interspersed below... On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote: Scott Haneda wrote, at 04/24/2009 07:58 AM: I am a little confused about main.cf and master.cf. Is there overlap in some of the settings? Do some settings exist in both files, or at least are interchangable? If this is the case, under what conditions do you decide to do so? From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer to other parameters as $name etc., just like in main.cf. See postconf(5) for syntax. As implied, it's useful when you need to override the settings in main.cf to get different behaviour appropriate to the service you're setting up in master.cf (submission, reinjection from proxy/filter, etc.). I have a little affliction against man type pages, they never seem to make a lot of sense to me :) This section does though. Just to be clear, this is a full blown over-ride, in that deleting the corresponding value from main.cf would do nothing to the server, so long as it exists in master.cf? [snip...] I am willing to disallow user connection to port 25. How do I do this? In main.cf or master.cf? Right now, I believe I only have this: [snip... master.cf ] smtp inet n - n - - smtpd I believe I need to add a restriction in there to stop clients from connecting? There was a recent thread on this subject, worth reading: http://www.mail-archive.com/postfix-users@postfix.org/msg06230.html Nice, thanks again, that was very telling. I will use that as a reference on how to best set this up, I think I still have some general questions below, as a result of my never having dealt with SSL/ TLS other than on ftp servers and SSL in the http space. For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. I can not seem to get this to work, it is either no encryption, or forced encryption. [snip... master.cf ] submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated -o milter_macro_daemon_name=ORIGINATING Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous If you do not like a lack of TLS enforcement on the submission port what do you suggest for users who just do not care enough to use any TLS? You let them work on port 25? I could go that route, but I am really trying to find a way to do traffic isolation. If I know no client connections are made on 25, from a troubleshooting perspective alone, it seems to make things simpler on me. My mailserver has a setting where I can disable auth on port 25. Maybe I will do this pre-migration, which would allow me to force all my users to change to port 25. The hobbly little server I am using now does not offer any way for me to look and see what users are connecting on 25 still. I think most are on 587 as a result of most ISP's filtering 25. Maybe a little tcpdump would get me those numbers. * Do I even need the milter line? Good question. It may depend on whether or not you use milters. I don't, but I leave it in because I don't want issues later if I decide to deploy a milter. Quick research seems to lead me to believe milter is for mail filtering, hence the name. Since I plan to have a proxy sit in front of my system, it should be safe to never use milter at all? I may want to auto file IMAP email to a junk mail folder, but I believe that would be done in dovecot, not postfix. Port 465, I believe will be reserved exclusively for SSL? Port 587 does the TLS, is that correct? Or is the SSL just wrapping around the TLS? [snip... master.cf ] 465 inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING This is for legacy support. I suggest you don't activate it until you're sure you need it. Wrapper mode is different from offering STARTTLS. Nearly all modern clients support STARTTLS. If someone absolutely needs port 465, that could be a red flag that the user needs an upgrade. However, some webmail programs might have poor support for STARTTLS, forcing you to enable smtps if you require an encrypted connection. Glad you brought up webmail. I am going to use Roundcube, on the same machine, worst case, on a close
Working with the postfix log files
As a test, I have disabled authenticated SMTP on port 25. I just fired up thunderbird, set the SMTP port to 25, and enabled SSL. Sending a test email, and I get an error back from the Thunderbird. Thunderbird chewed on this for a long time. My concern is what was in the logs. If a customer of mine is on the phone with me, and I tell them to make a connection, and the server is rather busy, I am not seeing anything I am going to be able to use form the logs, to help them out Apr 24 18:13:17 catalyst postfix/smtpd[831]: connect from c-76-102-xx1- xx.hsd1.ca.comcast.net[76.102.xx1.xx] Apr 24 18:14:21 catalyst postfix/smtpd[831]: lost connection after UNKNOWN from c-76-102-xx1-xx.hsd1.ca.comcast.net[76.102.xx1.xx] Apr 24 18:14:21 catalyst postfix/smtpd[831]: disconnect from c-76-102- xx1-xx.hsd1.ca.comcast.net[76.102.xx1.xx] I think I would have to ask them to locate their IP, then I could help them out. Suggestions? -- Scott * If you contact me off list replace talklists@ with scott@ *
Re: Suggestions on submission port config
2009/4/25 Scott Haneda talkli...@newgeo.com: I have a little affliction against man type pages, they never seem to make a lot of sense to me :) This section does though. Just to be clear, this is a full blown over-ride, in that deleting the corresponding value from main.cf would do nothing to the server, so long as it exists in master.cf? Not quite. It's an override for when you want to change the settings for a particular daemon. Overrides in master.cf don't propagate out to the rest of the config though. If you want a setting, put it in main.cf. If a particular process needs an override, *then* it goes in master.cf. A relevant example: For spam-filtering most people fill out smtpd_recipient_restrictions. smtpd_recipient_restrictions will be used for any smtpd process, which in master.cf is the lines like this: smtp inet n - - - - smtpd submission inet n - - - - smtpd smtps inet n - - - - smtpd A lot of the time you'd like a different set of smtpd_recipient_restrictions for the submission port. *That's* when you override it; you DO NOT delete the smtpd_recipient_restrictions from main.cf! Otherwise you'll get the default restrictions for your smtp and smtps ports. If you do not like a lack of TLS enforcement on the submission port what do you suggest for users who just do not care enough to use any TLS? You let them work on port 25? I could go that route, but I am really trying to find a way to do traffic isolation. If I know no client connections are made on 25, from a troubleshooting perspective alone, it seems to make things simpler on me. My mailserver has a setting where I can disable auth on port 25. Maybe I will do this pre-migration, which would allow me to force all my users to change to port 25. The hobbly little server I am using now does not offer any way for me to look and see what users are connecting on 25 still. I think most are on 587 as a result of most ISP's filtering 25. There's a few distinct concepts here: SSL and TLS. While it's not entirely accurate, it's easiest to think of it in this way: SSL is an encrypted pipe that goes around the smtp session. SSL is negotiated before SMTP starts and is transparent to the MTA at each end. This is why you can use tools like stunnel to setup transparent security for HTTP, SMTP, etc. TLS is negotiated in-band, at least for SMTP. The session starts in plaintext, the server offers STARTTLS in its reply to EHLO, the client can choose to initiate negotiation by sending STARTTLS, then the crypto kicks in and the session is protected. Each side then keeps talking SMTP as usual. http://en.wikipedia.org/wiki/STARTTLS Port 25 == regular SMTP, this must always be enabled if you want to receive mail from the internet Port 465 == de-facto port for running SSL-mode SMTP Port 587 == usual port for running TLS SMTP - this is exactly the same as port 25 however! You can talk plain SMTP to port 587 if you want, try it in a telnet session. Because port 25 and port 587 are configured separately in master.cf, you can have different settings. You can't enforce crypto on port 25, but you can do that on port 587 if you want. You can enforce the requirement to perform auth on port 587 if you want. Auth and crypto: these are separate things. MTAs can use opportunistic encryption across the internet even if they don't know each other; this is confidentiality without authentication. Given that regular mail transit is already unauthenticated, this can only be a net gain. Authentication is what you want your users to do before they can relay mail. In the context of SMTP it just means they prove their username and password to you, one way or another. Obviously it's bad if customers send their username and password in the clear, which is why you can tackle this in a couple of ways. 1. Require them to use a secure authentication protocol - this does *not* necessarily imply crypto, which is where a lot of confusion stems from. If you send me your password in plaintext, that's insecure. If we perform a challenge-response session, you send me a hash that allows me to verify your password, but your password was not transmitted, so attackers can't steal it - that's secure. Due to various reasons relating to secure storage of passwords, using an insecure auth protocol means I don't have to store a plaintext copy of your password on the server; that's a Good Thing. A secure auth protocol like CRAM-MD5 requires the server to have a plaintext or effectively-plaintext copy of your password, and that's not as nice. Note that even if I use a secure auth protocol, the rest of the mail session is unprotected and can be read by an attacker sniffing the wire. 2. The alternative is to wrap everything in a crypto pipe - this is SSL or TLS. Once the whole session is encrypted we don't care how authentication happens, as confidentiality is provided externally.
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/24/2009 07:41 PM: Thanks for this, this is getting me on track, comments interspersed below... On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote: Scott Haneda wrote, at 04/24/2009 07:58 AM: I am a little confused about main.cf and master.cf. Is there overlap in some of the settings? Do some settings exist in both files, or at least are interchangable? If this is the case, under what conditions do you decide to do so? From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer to other parameters as $name etc., just like in main.cf. See postconf(5) for syntax. As implied, it's useful when you need to override the settings in main.cf to get different behaviour appropriate to the service you're setting up in master.cf (submission, reinjection from proxy/filter, etc.). I have a little affliction against man type pages, they never seem to make a lot of sense to me :) This section does though. Just to be clear, this is a full blown over-ride, in that deleting the corresponding value from main.cf would do nothing to the server, so long as it exists in master.cf? Yes. But keep in mind that most settings have a default value. It's healthy to define a base configuration in main.cf, where your needs differ from the defaults, then only apply overrides in master.cf where necessary. For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous If you do not like a lack of TLS enforcement on the submission port what do you suggest for users who just do not care enough to use any TLS? I suggest they use it if they want to send mail. :) Since one of the purposes of the submission port is to support road warriors, I feel it should be as secure as possible and the entire communication should be encrypted. You let them work on port 25? In some cases, I allow the use of a secure mechanism without TLS on port 25. This protects the login, but not the message contents. I don't allow unencrypted plaintext logins. I could go that route, but I am really trying to find a way to do traffic isolation. If I know no client connections are made on 25, from a troubleshooting perspective alone, it seems to make things simpler on me. I think it's reasonable. Just give your users advance notice so they can change their settings. Glad you brought up webmail. I am going to use Roundcube, on the same machine, worst case, on a close machine, in the same subnet. Since I have the nynetworks setting set to allow mail, all should be ok? I do not want to deal with AUTH for SMTP in webmail, it is going to be local to local, I see no point in securing that part. Is that correct? It's up to you. I use SMTP AUTH for webmail, partly because it provides better logging for troubleshooting. I am confused about your comments about 465. Reading it makes me think that 465 is sort of a last resort option. I am not understanding the difference between SSL and TLS. If I was setting up a email client, and could use TLS versus SSL, my logic would be to use SSL, it seems the better option, but I do not know why. Are you saying SSL email is the lesser of the options, and I should use TLS when I can? I'm saying that smtps (wrapper mode on port 465) is deprecated in favor of STARTTLS on ports 25 or 587. So the ideal situation is using TLS on a non 25 submission port? Ideally, STARTTLS on the standardized submission port 587. Do you know how this related to Apple Mail? There is no setting in the SMTP section to opt for SSL versus TLS? Use SSL is the only checkbox there is. I take it if you do not select that, it will use TLS if it can, but do so in a invisible way? Default autoconfiguration appears to use ports 25, 465, 587 and SSL if detected. The server I tested supports all of these and the mechanism list is PLAIN LOGIN CRAM-MD5 DIGEST-MD5. After autoconfiguration, Apple Mail used STARTTLS and the PLAIN mechanism on port 25 to send a message. I assume it follows an algorithm to determine a fallback strategy for trying the other ports if its first choice is not available. Although I would have preferred it start with port 587, the choice it made is acceptably secure. If you only offer port 587, it probably won't pose any problems (as long as it remembers the other ports are unavailable). In any case, you can set the port mechanism explicitly, and it will negotiate TLS/SSL appropriately for either wrapper mode or STARTTLS. It
