Connection lost on mail send
Dear All Now I have setup email system in my host. I am able to receive the mail. But when I try to send mail I get below error *SMTP Error (-1): Connection to server failed.* I am sure, port SMTPD is running at 587 (I can do telnet). Then I checked the error log, I see *postfix/submission/smtpd[1629]: connect from localhost[127.0.0.1]postfix/submission/smtpd[1629]: lost connection after UNKNOWN from localhost[127.0.0.1]* I am not sure, why postfix is refusing connection even if telnet to 587 port is successful. Thanks Austin
Re: Connection lost on mail send
Am 22.10.2014 um 10:49 schrieb Austin Einter: Then I checked the error log, I see /*postfix/submission/smtpd[1629]: connect from localhost[127.0.0.1] postfix/submission/smtpd[1629]: lost connection after UNKNOWN from localhost[127.0.0.1]*/ I am not sure, why postfix is refusing connection even if telnet to 587 port is successful where do you see here postfix refuse anything? *lost* connection != refused connection postfix is just the messenger
Re: Connection lost on mail send
This issue was resolved by changing port to 465. Not sure why 587 do not work. On Wed, Oct 22, 2014 at 2:39 PM, li...@rhsoft.net li...@rhsoft.net wrote: Am 22.10.2014 um 10:49 schrieb Austin Einter: Then I checked the error log, I see /*postfix/submission/smtpd[1629]: connect from localhost[127.0.0.1] postfix/submission/smtpd[1629]: lost connection after UNKNOWN from localhost[127.0.0.1]*/ I am not sure, why postfix is refusing connection even if telnet to 587 port is successful where do you see here postfix refuse anything? *lost* connection != refused connection postfix is just the messenger
Re: Connection lost on mail send
Am 22.10.2014 um 11:53 schrieb Austin Einter: This issue was resolved by changing port to 465. Not sure why 587 do not work. because you need to understand that 587 is STARTTLS and 465 is not and so you need the correct client configuration for the port https://www.fastmail.fm/help/technical/ssltlsstarttls.html you did not mention in your OP SSL at all but be ware that telnet in context of SSL makes no sense On Wed, Oct 22, 2014 at 2:39 PM, li...@rhsoft.net: Am 22.10.2014 um 10:49 schrieb Austin Einter: Then I checked the error log, I see /*postfix/submission/smtpd[__1629]: connect from localhost[127.0.0.1] postfix/submission/smtpd[1629]__: lost connection after UNKNOWN from localhost[127.0.0.1]*/ I am not sure, why postfix is refusing connection even if telnet to 587 port is successful where do you see here postfix refuse anything? *lost* connection != refused connection postfix is just the messenger
Re: Connection lost on mail send
On Wednesday, October 22, 2014, 4:53:35 AM, Austin wrote: This issue was resolved by changing port to 465. Not sure why 587 do not work. When using port 587, the e-mail client has to send STARTTLS to establish a connection. Check to see if your e-mail client has such a setting. Using the old port 465, the incoming connection is expected to already be secure. This is a port the old Microsoft e-mail clients used years ago. Although port 465 is still supported, you really should get port 587 working as it is the standard in today's day and age. On Wed, Oct 22, 2014 at 2:39 PM, li...@rhsoft.net li...@rhsoft.net wrote: Am 22.10.2014 um 10:49 schrieb Austin Einter: Then I checked the error log, I see /*postfix/submission/smtpd[1629]: connect from localhost[127.0.0.1] postfix/submission/smtpd[1629]: lost connection after UNKNOWN from localhost[127.0.0.1]*/ I am not sure, why postfix is refusing connection even if telnet to 587 port is successful where do you see here postfix refuse anything? *lost* connection != refused connection postfix is just the messenger -- Duane Hill duih...@gmail.com If at first you don't succeed, so much for sky diving.
New Email Account Creation Failed
Dear All Now I am able to send receive mail from my domain. Now I wanted to create new email accounts using below command. useradd -s /sbin/nologin username passwd username User is added to machine. Next I tried to login to that account from my mail client, it fails. When I checked /var/mail folder I do not see any new account mail file there. Previously I had created one account, and I see corresponding mail file is present in /var/mail path My question is what is the correct way of adding a new mail account in postfix/dovecot based email systems. The mail file should be of what permission. Many thanks Austin
Re: R: postfix TLS question
Salvatore Palazzolo: Dear Wietse. We already discuss about a TLS question a lot of months ago. I have now an other question for you. Is it possible avoid that if my Postfix send an email to an External Domain which is required to be encrypt in TLS, the email is kept in deferred queue? We would like in that case reject that because we think that it?s a permanent error for us and we would like advise the sender as soon as possible of the error. http://www.postfix.org/postconf.5.html#smtp_delivery_status_filter Wietse
Re: New Email Account Creation Failed
I just want to know how new email accounts are created. When I create a new user, by default I expect a mail file should be created in /var/mail/ or /var/mail/domain folder. Is not it the case? Kindly let me know, what is the right procedure to create a new mail account for postfix+dovecot email server. Thanks Austin On Wed, Oct 22, 2014 at 4:31 PM, Austin Einter austin.ein...@gmail.com wrote: Dear All Now I am able to send receive mail from my domain. Now I wanted to create new email accounts using below command. useradd -s /sbin/nologin username passwd username User is added to machine. Next I tried to login to that account from my mail client, it fails. When I checked /var/mail folder I do not see any new account mail file there. Previously I had created one account, and I see corresponding mail file is present in /var/mail path My question is what is the correct way of adding a new mail account in postfix/dovecot based email systems. The mail file should be of what permission. Many thanks Austin
Re: New Email Account Creation Failed
Austin Einter: I just want to know how new email accounts are created. This is the POSTFIX mailing list. Postfix does not manage accounts. Accounts are managed with DOVECOT. Wietse When I create a new user, by default I expect a mail file should be created in /var/mail/ or /var/mail/domain folder. Is not it the case? Kindly let me know, what is the right procedure to create a new mail account for postfix+dovecot email server. Thanks Austin On Wed, Oct 22, 2014 at 4:31 PM, Austin Einter austin.ein...@gmail.com wrote: Dear All Now I am able to send receive mail from my domain. Now I wanted to create new email accounts using below command. useradd -s /sbin/nologin username passwd username User is added to machine. Next I tried to login to that account from my mail client, it fails. When I checked /var/mail folder I do not see any new account mail file there. Previously I had created one account, and I see corresponding mail file is present in /var/mail path My question is what is the correct way of adding a new mail account in postfix/dovecot based email systems. The mail file should be of what permission. Many thanks Austin
Idea: multiple actions in access/header_checks/policy results
The basic idea is to permit more than one action in an access(5) or
header_checks(5) table lookup result or SMTPD policy response:
A few examples to clarify:
/etc/postfix/access:
# The new multi-action form.
1.2.3.4 { prepend header text... } other actions...
/etc/postfix/header_checks:
# prepend+ignore should be equivalent to replace.
/foo/ { prepend replacement header text... } ignore
policy service:
# The new multi-action form.
action = { prepend new header text... } other actions...
In all cases the historical one-action form still works as before.
Remember that Postfix access maps and policy service replies may
contain the same things that are used in smtpd_mumble_restrictions?
With the above syntax means we can now also use all the access(5)
map results in smtpd_mumble_restrictions:
/etc/postfix/main.cf:
smtpd_mumble_restrictions = ... { defer text... }
smtpd_mumble_restrictions = ... { defer_if_permit text... } ...
Why not use the form command { arguments... }? The reason is that
historically, commands like defer and reject have no arguments
when used in smtpd_mumble_restrictions. In order to give those
commands arguments we need the form { command arguments... }.
This way we avoid breaking the compatibility of core Postfix features
such as defer and reject.
For consistency, the same { command args.. } form must then be
used in access(5) or header_checks(5) table lookup results, and
in SMTPD policy responses.
Wietse
Re: Idea: multiple actions in access/header_checks/policy results
Am 22.10.2014 um 15:49 schrieb Wietse Venema:
The basic idea is to permit more than one action in an access(5) or
header_checks(5) table lookup result or SMTPD policy response:
A few examples to clarify:
/etc/postfix/access:
# The new multi-action form.
1.2.3.4 { prepend header text... } other actions...
/etc/postfix/header_checks:
# prepend+ignore should be equivalent to replace.
/foo/ { prepend replacement header text... } ignore
policy service:
# The new multi-action form.
action = { prepend new header text... } other actions...
In all cases the historical one-action form still works as before.
Remember that Postfix access maps and policy service replies may
contain the same things that are used in smtpd_mumble_restrictions?
With the above syntax means we can now also use all the access(5)
map results in smtpd_mumble_restrictions:
/etc/postfix/main.cf:
smtpd_mumble_restrictions = ... { defer text... }
smtpd_mumble_restrictions = ... { defer_if_permit text... } ...
Why not use the form command { arguments... }? The reason is that
historically, commands like defer and reject have no arguments
when used in smtpd_mumble_restrictions. In order to give those
commands arguments we need the form { command arguments... }.
This way we avoid breaking the compatibility of core Postfix features
such as defer and reject.
For consistency, the same { command args.. } form must then be
used in access(5) or header_checks(5) table lookup results, and
in SMTPD policy responses
sounds interesting
what i would love is more than one lookup key like specify a action for
a pair sender rcpt action what would it make really easy do define
whitelists and blacklists in access tables
@postfix.org @rhsoft.net OK
@example.org @rhsoft.net REJECT
a...@example.org li...@rhsoft.net REJECT
that way and combined with a simple database scheme one could build more
or less complex rules and save for many cases a policy daemon
Multi-key queries (was: multiple actions in access/header_checks/policy results)
li...@rhsoft.net:
what i would love is more than one lookup key like specify a action for
a pair sender rcpt action what would it make really easy do define
whitelists and blacklists in access tables
@postfix.org @rhsoft.net OK
@example.org @rhsoft.net REJECT
a...@example.org li...@rhsoft.net REJECT
Perhaps 18 years from today the coin will drop again. But I do not
expect that Postfix will ever have multi-key tables.
More practical would be a lookup key generator whose output is piped
into a single-key lookup table:
/etc/postfix/main.cf:
smtpd_mumble_rerstrictions =
...
pipemap:{makekey:{sender|recipient}, hash:/etc/postfix/access}
...
/etc/postfix/access:
xxx|yyy reject...
This could result in a lot of queries (sender with/without domain
with/without address extension, and recipient with/without domain
with/without address extension).
Wietse
Re: Idea: multiple actions in access/header_checks/policy results
On Wed, Oct 22, 2014 at 04:00:14PM +0200, li...@rhsoft.net wrote: What I would love is more than one lookup key, for example to specify an action for a sender/recipient pair. This would it make really easy to define whitelists and blacklists in access tables For now, this can be done with policy services. -- Viktor.
Re: Idea: multiple actions in access/header_checks/policy results
Am 22.10.2014 um 16:22 schrieb Viktor Dukhovni: On Wed, Oct 22, 2014 at 04:00:14PM +0200, li...@rhsoft.net wrote: What I would love is more than one lookup key, for example to specify an action for a sender/recipient pair. This would it make really easy to define whitelists and blacklists in access tables For now, this can be done with policy services well, i know that, hence i wrote and save for many cases a policy daemon in my original message :-)
check_sender_access not running the specified action
I'm running Postfix 2.11 and I'm having some issues with the check_sender_access parameter. Currently my configuration for sender restrictions is the following: smtpd_sender_restrictions = permit_mynetworks check_sender_access hash:/etc/postfix/valid_senders reject_unknown_sender_domain reject_sender_login_mismatch reject_unauth_pipelining reject_non_fqdn_sender permit The /etc/postfix/valid_senders file has this content: t...@live.com REJECT usuarios.atresplayer.com REJECT This domain doesn't wish to receive more e-mails from you. Evidently, it has been 'postmapped'. The fact is that currently any mail sent from *@usuarios.atresplayer.com is being allowed. Relevant headers from incoming mails are the following: From: ATRESMEDIA NEWS comunicacion_atrespla...@usuarios.atresplayer.com x-sender: comunicacion_atrespla...@usuarios.atresplayer.com I have made some other tests (for example, REJECTing my complete gmail address) and the e-mail gets correctly rejected in that case. What could be reason why that domain is not being rejected with the mentioned configuration? Thanks.
Re: check_sender_access not running the specified action
On Wed, Oct 22, 2014 at 07:41:22PM +0100, Nicol?s wrote: The claim in the subject line is simply implausible. Such major problems in access(5) processing would not go unnoticed. smtpd_sender_restrictions = permit_mynetworks check_sender_access hash:/etc/postfix/valid_senders Mail that passes these two conditions is either sent from a client that matches permit_mynetworks (checks logs or Received headers for client IP) or from an *envelope sender* address that is not blocked by that table. Relevant headers from incoming mails are the following: From: ATRESMEDIA NEWS comunicacion_atrespla...@usuarios.atresplayer.com x-sender: comunicacion_atrespla...@usuarios.atresplayer.com Not actually relevant, since this is not the *envelope sender* address. -- Viktor.
Re: check_sender_access not running the specified action
El 22/10/2014 a las 19:47, Viktor Dukhovni escribió: Mail that passes these two conditions is either sent from a client that matches permit_mynetworks (checks logs or Received headers for client IP) or from an *envelope sender* address that is not blocked by that table. Ok, this would explain the behavior, since the envelope sender is different. I assumed it was the 'FROM' header the one that was matched. Thank you.
Fw: table lookup problems warnings and not critical?
Hi, This weekend a MySQL server which backends a couple of postfix servers went down for a couple of hours without anyone noticing and I'm looking to setup some monitoring so that it doesn't go unnoticed again in future. I thought a good start would be a look though the syslogs for entries with a priority of critical but I found nothing. If i searched for warnings and found the messages I was looking for (warning: proxy:mysql:/usr/local/etc/postfix/mysql/mynetworks.cf: table lookup problem) but I also found a lot of mesages I wasn't interested in.. eg.. warning: Illegal address syntax from unknown[186.136.28.57] in MAIL command: quot;Microsoft Outlookquot; lt;no-re...@fibertel.com.argt; warning: hostname outboundmail1.contractsfinder.businesslink.gov.uk does not resolve to address 5.79.34.51 etc So I have two questions. 1) Is it right that a 'table lookup problem' is only a warning and not a critical event? In my setup I would feel it was a critical event and I would guess it would be in most peoples setups if they've gone to the trouble of using a SQL backend. 2) Is there any way to make a 'table lookup problem' syslog as critial for my setup ? Kind regards Steve DISCLAIMER This email is for the use of the intended recipient(s) only. If you have received this email in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the authors prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. The information contained in this communication may be confidential and may be subject to the attorney-client privilege. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future then please respond to the sender to this effect.
Re: Fw: table lookup problems warnings and not critical?
steve: 1) Is it right that a 'table lookup problem' is only a warning and not a critical event? In my setup I would feel it was a critical event and I would guess it would be in most peoples setups if they've gone to the trouble of using a SQL backend. That depends on the purpose of the table lookup. For example, if the error could result in a delivery error, then the error is critical and Postfix defers delivery. I see no error context and no configuration information, so I will not speculate what the purpose of the lookup was. 2) Is there any way to make a 'table lookup problem' syslog as critial for my setup ? Criticality is determined by the purpose of the lookup. Wietse
Re-2: Fw: table lookup problems warnings and not critical?
Hi, Thankyou for taking the time to reply. All maps on my setup are MySQL backed. I have no local mail as such. All domains are virtual (I think that's the correct postfix terminology?) # postconf | grep mysql debug_peer_list = proxy:mysql:/usr/local/etc/postfix/mysql/debug_peer_list.cf mynetworks = proxy:mysql:/usr/local/etc/postfix/mysql/mynetworks.cf relay_domains = proxy:mysql:/usr/local/etc/postfix/mysql/relay_domains-sa-learn.cf, proxy:mysql:/usr/local/etc/postfix/mysql/relay_domains.cf relay_recipient_maps = proxy:mysql:/usr/local/etc/postfix/mysql/relay_recipient_maps.cf, proxy:mysql:/usr/local/etc/postfix/mysql/relay_recipient_maps_catchall.cf, proxy:mysql:/usr/local/etc/postfix/mysql/relay_recipient_maps_postmaster.cf smtpd_client_restrictions = check_client_access proxy:mysql:/usr/local/etc/postfix/mysql/smtpd_client_restrictions-check_client_access.cf, check_client_access hash:/usr/local/etc/postfix/smtpd_client_restrictions-check_client_access-internal-mailservers smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_recipient_domain, check_recipient_access proxy:mysql:/usr/local/etc/postfix/mysql/smtpd_recipient_restrictions-check_recipient_access.cf, check_sender_access hash:/usr/local/etc/postfix/smtpd_recipient_restrictions-check_sender_access, permit_mynetworks, permit_sasl_authenticated, reject_unknown_sender_domain, reject_unauth_destination, check_client_access proxy:mysql:/usr/local/etc/postfix/mysql/smtpd_recipient_restrictions-check_client_access.cf check_client_access proxy:mysql:/usr/local/etc/postfix/mysql/smtpd_client_restrictions-check_client_access.cf, check_client_access hash:/usr/local/etc/postfix/smtpd_client_restrictions-check_client_access-internal-mailservers, check_client_access proxy:mysql:/usr/local/etc/postfix/mysql/postfix_whitelisted_servers.cf check_reverse_client_hostname_access pcre:/usr/local/etc/postfix/maps/fqrdns.pcre, reject_rbl_client zen.spamhaus.org=127.0.0.10, reject_rbl_client zen.spamhaus.org=127.0.0.11, reject_rbl_client zen.spamhaus.org, permit # postconf | grep mail_version mail_version = 2.11.1 That depends on the purpose of the table lookup. For example, if the error could result in a delivery error, then the error is critical and Postfix defers delivery. That makes sense. The problem is in my case it did't result in a delivery error, it resulted in a taking of delivery error. The servers failed to receive any email for a couple of hours as a result of the MySQL outage. Here's an example of the kind of messages I have on my logs... 2014-10-18T00:00:13.000+01:00 maroon postfix/smtpd[75860]: connect from unknown[213.199.154.78] 2014-10-18T00:01:28.000+01:00 maroon postfix/smtpd[75860]: warning: proxy:mysql:/usr/local/etc/postfix/mysql/debug_peer_list.cf: table lookup problem 2014-10-18T00:02:43.000+01:00 maroon postfix/smtpd[75860]: warning: proxy:mysql:/usr/local/etc/postfix/mysql/mynetworks.cf: table lookup problem 2014-10-18T00:03:13.000+01:00 maroon postfix/smtpd[75860]: warning: milter inet:127.0.0.1:8891: can't read SMFIC_CONNECT reply packet header: Operation timed out 2014-10-18T00:05:16.000+01:00 maroon postfix/smtpd[75860]: warning: proxy:mysql:/usr/local/etc/postfix/mysql/mynetworks.cf: table lookup problem 2014-10-18T00:05:16.000+01:00 maroon postfix/smtpd[75860]: Anonymous TLS connection established from unknown[213.199.154.78]: TLSv1 with cipher AES256-SHA (256/256 bits) 2014-10-18T00:05:16.000+01:00 maroon postfix/smtpd[75860]: warning: proxy:mysql:/usr/local/etc/postfix/mysql/mynetworks.cf: table lookup problem 2014-10-18T00:05:16.000+01:00 maroon postfix/smtpd[75860]: warning: proxy:mysql:/usr/local/etc/postfix/mysql/mynetworks.cf: table lookup problem 2014-10-18T00:05:16.000+01:00 maroon postfix/smtpd[75860]: lost connection after EHLO from unknown[213.199.154.78] A 'table lookup problem' resulting is not being able to take receipt of email is a critical situation in my setup. Any help gratefully received! Regards Steve Original Message Subject: Re: Fw: table lookup problems warnings and not critical? (22-Oct-2014 21:18) From:wie...@porcupine.org To: postfix-us...@spectrumcs.net steve: 1) Is it right that a 'table lookup problem' is only a warning and not a critical event? In my setup I would feel it was a critical event and I would guess it would be in most peoples setups if they've gone to the trouble of using a SQL backend. That depends on the purpose of the table lookup. For example, if the error could result in a delivery error, then the error is critical and Postfix defers delivery. I see no error context and no configuration information, so I will not speculate what the purpose of the lookup was. 2) Is there any way to make a 'table lookup problem' syslog as critial for my setup ? Criticality is determined by the purpose of the lookup. Wietse To:
Re: Re-2: Fw: table lookup problems warnings and not critical?
steve: Hi, Thankyou for taking the time to reply. All maps on my setup are MySQL backed. I have no local mail as such. All domains are virtual (I think that's the correct postfix terminology?) # postconf | grep mysql [lotsa maps] That depends on the purpose of the table lookup. For example, if the error could result in a delivery error, then the error is critical and Postfix defers delivery. That makes sense. The problem is in my case it did't result in a delivery error, it resulted in a taking of delivery error. The servers failed to receive any email for a couple of hours as a result of the MySQL outage. Here's an example of the kind of messages I have on my logs... You mean, Postfix deferred the mail transaction, instead of making the wrong decision what mail to reject or accept, and instead of making the wrong decision where to deliver mail. 2014-10-18T00:02:43.000+01:00 maroon postfix/smtpd[75860]: warning: proxy:mysql:/usr/local/etc/postfix/mysql/mynetworks.cf: table lookup problem [lots more table lookup errors] 2014-10-18T00:05:16.000+01:00 maroon postfix/smtpd[75860]: lost connection after EHLO from unknown[213.199.154.78] A 'table lookup problem' resulting is not being able to take receipt of email is a critical situation in my setup. Yes. Postfix defers delivery when database lookup fails that could result in accepting or rejecting the wrong mail or delivering mail to the wrong place. It is your responsibility to take action when Postfix logs database lookup errors. I suggest that you run a logfile watcher that raises an alarm. Wietse
Re-4: Fw: table lookup problems warnings and not critical?
Original Message Subject: Re: Re-2: Fw: table lookup problems warnings and not critical? (22-Oct-2014 22:16) From:wie...@porcupine.org To: postfix-us...@spectrumcs.net steve: Hi, Thankyou for taking the time to reply. All maps on my setup are MySQL backed. I have no local mail as such. All domains are virtual (I think that's the correct postfix terminology?) # postconf | grep mysql [lotsa maps] That depends on the purpose of the table lookup. For example, if the error could result in a delivery error, then the error is critical and Postfix defers delivery. That makes sense. The problem is in my case it did't result in a delivery error, it resulted in a taking of delivery error. The servers failed to receive any email for a couple of hours as a result of the MySQL outage. Here's an example of the kind of messages I have on my logs... You mean, Postfix deferred the mail transaction, instead of making the wrong decision what mail to reject or accept, and instead of making the wrong decision where to deliver mail. Sorry, just to clarify the servers I'm talking about at internet facing, accepting emails from the internet for domains I've configured my postfix(s) as being virtual. 2014-10-18T00:02:43.000+01:00 maroon postfix/smtpd[75860]: warning: proxy: mysql:/usr/local/etc/postfix/mysql/mynetworks.cf: table lookup problem [lots more table lookup errors] 2014-10-18T00:05:16.000+01:00 maroon postfix/smtpd[75860]: lost connection after EHLO from unknown[213.199.154.78] A 'table lookup problem' resulting is not being able to take receipt of email is a critical situation in my setup. Yes. Postfix defers delivery when database lookup fails that could result in accepting or rejecting the wrong mail or delivering mail to the wrong place. From looking at my logs I don't see postfix is defering anything with a 5XX status, it's instead letting the connection from the inbound SMTP server timeout. Hence why I felt it should be a critical alert in the logs. It is your responsibility to take action when Postfix logs database lookup errors. I suggest that you run a logfile watcher that raises an alarm. I'll look into that. My concern would be that I can setup a logfile watcher to look for database lookup errors but what if my next problem is something else I'm not currently looking for. Is it possible to get a list of all the possible postfix warnings it could log? Perhaps I asked the wrong question at the begining of this thread. Perhaps the question should be... should Illegal address syntax from unknown[A.B.C.D] or hostname W.X.Y.Z does not resolve to address 111.222.333.444 be classed as warnings? I feel a table lookup problem is more severe than a Illegal address syntax from or hostname does not resolve to address problem. Perhaps Illegal address syntax from or hostname does not resolve to address should be logged as info or debug? Kind regards Steve DISCLAIMER This email is for the use of the intended recipient(s) only. If you have received this email in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the authors prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. The information contained in this communication may be confidential and may be subject to the attorney-client privilege. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future then please respond to the sender to this effect.
Re: Fw: table lookup problems warnings and not critical?
On 10/22/2014 2:45 PM, steve wrote: Hi, This weekend a MySQL server which backends a couple of postfix servers went down for a couple of hours without anyone noticing and I'm looking to setup some monitoring so that it doesn't go unnoticed again in future. There are really only two good options for monitoring postfix. + base level monitoring -- is postfix master process running? bonus points: see if postfix answers with a 220 response on the smtp port. + operational monitoring -- a process submits a message periodically, another process monitors the target mailbox to see if a message arrives periodically. Anything in between is pretty meaningless. In the case of a broken lookup table interrupting receiving mail, only operational monitoring would reveal that.
Internationalized Email now supported by amavisd (SMTPUTF8, EAI, IDN)
To go hand-in-hand with the Postfix support for Internationalized Email, the new version 2.10.0 of amavisd mail content filter was released today. So now that we have it covered at an MTA and at a content filter stages, it's perhaps time to step up the heat on developers of mail clients and IMAP servers, reminding them that RFC 6530 is now two and a half years old, and that only 5.43 % of the world population are native speakers of English (2007) according to Wikipedia/Nationalencyklopedin: https://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers Key new features: - added support for Internationalized Email: * RFC 6530 - Overview and Framework for Internationalized Email * RFC 6531 - SMTP Extension for Internationalized Email (SMTPUTF8) * RFC 6532 - Internationalized Email Headers * RFC 6533 - Internationalized Delivery Status Notifications This supports UTF-8 (EAI) in SMTP/LMTP sender addresses, recipient addresses, and message header section. Feature parity with Postfix version 2.12 (support introduced in development snapshot 20140715). The SMTPUTF8 extension is supported by Gmail since 2014-08-05: http://googleblog.blogspot.com/2014/08/a-first-step-toward-more-global-email.html - added support for Internationalized Domain Names (IDN) according to IDNA (RFC 5890, RFC 5891; RFC 3490); Release notes are at: http://www.ijs.si/software/amavisd/release-notes.txt Download at: http://www.ijs.si/software/amavisd/amavisd-new-2.10.0.tar.xz Mark
Re: Internationalized Email now supported by amavisd (SMTPUTF8, EAI, IDN)
Mark Martinec: To go hand-in-hand with the Postfix support for Internationalized Email, the new version 2.10.0 of amavisd mail content filter was released today. Thanks, Mark. Wietse So now that we have it covered at an MTA and at a content filter stages, it's perhaps time to step up the heat on developers of mail clients and IMAP servers, reminding them that RFC 6530 is now two and a half years old, and that only 5.43 % of the world population are native speakers of English (2007) according to Wikipedia/Nationalencyklopedin: https://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers Key new features: - added support for Internationalized Email: * RFC 6530 - Overview and Framework for Internationalized Email * RFC 6531 - SMTP Extension for Internationalized Email (SMTPUTF8) * RFC 6532 - Internationalized Email Headers * RFC 6533 - Internationalized Delivery Status Notifications This supports UTF-8 (EAI) in SMTP/LMTP sender addresses, recipient addresses, and message header section. Feature parity with Postfix version 2.12 (support introduced in development snapshot 20140715). The SMTPUTF8 extension is supported by Gmail since 2014-08-05: http://googleblog.blogspot.com/2014/08/a-first-step-toward-more-global-email.html - added support for Internationalized Domain Names (IDN) according to IDNA (RFC 5890, RFC 5891; RFC 3490); Release notes are at: http://www.ijs.si/software/amavisd/release-notes.txt Download at: http://www.ijs.si/software/amavisd/amavisd-new-2.10.0.tar.xz Mark
Re: New Email Account Creation Failed
According to the tutorial you followed you don't need to make a system user for them to get mail. Just add them to the sql database. The mailbox location is specified in /etc/dovecot/conf.d/10-mail.conf with mail_location = /path/to/mailbox On 10/22/2014 07:41 AM, Wietse Venema wrote: Austin Einter: I just want to know how new email accounts are created. This is the POSTFIX mailing list. Postfix does not manage accounts. Accounts are managed with DOVECOT. Wietse When I create a new user, by default I expect a mail file should be created in /var/mail/ or /var/mail/domain folder. Is not it the case? Kindly let me know, what is the right procedure to create a new mail account for postfix+dovecot email server. Thanks Austin On Wed, Oct 22, 2014 at 4:31 PM, Austin Einter austin.ein...@gmail.com wrote: Dear All Now I am able to send receive mail from my domain. Now I wanted to create new email accounts using below command. useradd -s /sbin/nologin username passwd username User is added to machine. Next I tried to login to that account from my mail client, it fails. When I checked /var/mail folder I do not see any new account mail file there. Previously I had created one account, and I see corresponding mail file is present in /var/mail path My question is what is the correct way of adding a new mail account in postfix/dovecot based email systems. The mail file should be of what permission. Many thanks Austin
