Re: block 'new style' TLDs ?
On 23 Oct 2019, at 15:20, lists wrote: > > /\.asia$/ 510 Denied: Unacceptable TLD .asia [Long list… removed] smtpd_helo_restrictions = reject_invalid_helo_hostname check_helo_access pcre:/etc/postfix/helo_checks.pcre permit /etc/postfix/helo_checks.pcre: /.*\.(com|net|org|edu|gov|ca|mx|de|dk|fi|fr|uk|us|tv|info|biz|eu|es|il|it|nl|name|jp|host|au|nz|ch|tv)$/ DUNNO /.*\.*$/ 550 Mail to or from this TLD is not allowed Of course your list will differ than mine, but I find this much better than reacting to which of these new garbage TLDs are spamming me this week. -- Anybody who could duck the Vietnam war can certainly duck a couple of shoes.
Re: Rewrite From header from old to new style
Hi Dominic How can I set gmail not top-posted? Its default reply is at the top. I have read the article, unfortunately I want to forward all messages not to create filters against special conditions. Someone told me can forward to a commercial pobox account then pobox has the ability to forward to multiple addresses. I am looking into it. Thank you. Maggie Dominic Raferd > On Wed, 23 Oct 2019 at 16:54, Maggie Q Roth wrote: > >> Hi I am newbie on technology sorry. >> Do you know how I setup gmail to forward to a group of other emails? >> From their webmail I can setup the only one. Will postfix do this stuff? >> Maggie >> > > This is not really a postfix question, you've posted it as an answer to an > existing thread, and you've top-posted. But no matter: at the time of > writing there are instructions for your requirement at > https://www.makeuseof.com/tag/how-to-auto-forward-emails-to-multiple-addresses-in-gmail/. > Postfix can do this and more but it may be overkill for what you are trying > to achieve. >
Re: Problem with new installation
On Wed, Oct 23, 2019 at 06:11:15PM -0400, Steve Matzura wrote:
> OK, I'm a rank amateur at this. I'll take the CNAME record out.
Note that despite RFC2181 a non-trivial fraction of domains do set
the "exchange" portion of an MX RR to a name that is a CNAME alias.
I am not aware of any MTAs that reject or fail to be able to use
such MX records.
> My MX record looks OK with "10 mail.{my-FQDN}". I will create an A record
> called mail which will point to my machine's IP address.
And yet, this is the preferred configuration.
> I have no NS records at this time.
I assume you do have NS records at the zone cut (perhaps "my-FQDN"
or wherever your domain is delegated to you from some registry,
just none for "mail.my-FQDN"). At the zone cut, an SOA RR, and
NS RRs are required.
--
Viktor.
Re: Problem with new installation
OK, I'm a rank amature at this. I'll take the CNAME record out. My mx
record looks OK with "10 mail.{my-FQDN}". I will create an A record
called mail which will point to my machine's IP address. I have no NS
records at this time.
On 10/23/2019 3:41 PM, @lbutlr wrote:
On 23 Oct 2019, at 12:33, Steve Matzura wrote:
I change the DNS record for mail from A to CNAME
Don’t do that.
https://tools.ietf.org/html/rfc2181
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
(An A or record is required)
Re: block 'new style' TLDs ?
As an aside, I have stopped some real live human beings from getting these dumb TLDs. Apparently "design" is one that is becoming popular for obvious but wrong headed reasons. https://en.m.wikipedia.org/wiki/.design Original Message From: xxdpp...@yahoo.com Sent: October 23, 2019 1:49 PM To: postfix-users@postfix.org Subject: Re: block 'new style' TLDs ? I've had the same problem for some time. I put the following into access_helo and header_checks. It's pretty severe (and the list gets bigger every month) but the percentage of valid email coming from those domains is next to nil. I use a 510 rather than a 554 reject so hopefully they won't try again. # Invalid and disreputable TLDs /\.asia$/ 510 Denied: Unacceptable TLD .asia /\.best$/ 510 Denied: Unacceptable TLD .best /\.bid$/ 510 Denied: Unacceptable TLD .bid /\.club$/ 510 Denied: Unacceptable TLD .club /\.date$/ 510 Denied: Unacceptable TLD .date /\.domain$/ 510 Denied: Unacceptable TLD .domain /\.faith$/ 510 Denied: Unacceptable TLD .faith /\.host$/ 510 Denied: Unacceptable TLD .host /\.icu$/ 510 Denied: Unacceptable TLD .icu /\.internal$/ 510 Denied: Unacceptable TLD .internal /\.lan$/ 510 Denied: Unacceptable TLD .lan /\.loan$/ 510 Denied: Unacceptable TLD .loan /\.local$/ 510 Denied: Unacceptable TLD .local /\.ninja$/ 510 Denied: Unacceptable TLD .ninja /\.online$/ 510 Denied: Unacceptable TLD .online /\.party$/ 510 Denied: Unacceptable TLD .party /\.pro$/ 510 Denied: Unacceptable TLD .pro /\.ren$/ 510 Denied: Unacceptable TLD .ren /\.review$/ 510 Denied: Unacceptable TLD .review /\.science$/ 510 Denied: Unacceptable TLD .science /\.site$/ 510 Denied: Unacceptable TLD .site /\.space$/ 510 Denied: Unacceptable TLD .space /\.stream$/ 510 Denied: Unacceptable TLD .stream /\.tech$/ 510 Denied: Unacceptable TLD .tech /\.top$/ 510 Denied: Unacceptable TLD .top /\.trade$/ 510 Denied: Unacceptable TLD .trade /\.vip$/ 510 Denied: Unacceptable TLD .vip /\.website$/ 510 Denied: Unacceptable TLD .website /\.win$/ 510 Denied: Unacceptable TLD .win /\.zone$/ 510 Denied: Unacceptable TLD .zone
Re: block 'new style' TLDs ?
I've had the same problem for some time. I put the following into access_helo and header_checks. It's pretty severe (and the list gets bigger every month) but the percentage of valid email coming from those domains is next to nil. I use a 510 rather than a 554 reject so hopefully they won't try again. # Invalid and disreputable TLDs /\.asia$/ 510 Denied: Unacceptable TLD .asia /\.best$/ 510 Denied: Unacceptable TLD .best /\.bid$/ 510 Denied: Unacceptable TLD .bid /\.club$/ 510 Denied: Unacceptable TLD .club /\.date$/ 510 Denied: Unacceptable TLD .date /\.domain$/ 510 Denied: Unacceptable TLD .domain /\.faith$/ 510 Denied: Unacceptable TLD .faith /\.host$/ 510 Denied: Unacceptable TLD .host /\.icu$/ 510 Denied: Unacceptable TLD .icu /\.internal$/ 510 Denied: Unacceptable TLD .internal /\.lan$/ 510 Denied: Unacceptable TLD .lan /\.loan$/ 510 Denied: Unacceptable TLD .loan /\.local$/ 510 Denied: Unacceptable TLD .local /\.ninja$/ 510 Denied: Unacceptable TLD .ninja /\.online$/ 510 Denied: Unacceptable TLD .online /\.party$/ 510 Denied: Unacceptable TLD .party /\.pro$/ 510 Denied: Unacceptable TLD .pro /\.ren$/ 510 Denied: Unacceptable TLD .ren /\.review$/ 510 Denied: Unacceptable TLD .review /\.science$/ 510 Denied: Unacceptable TLD .science /\.site$/ 510 Denied: Unacceptable TLD .site /\.space$/ 510 Denied: Unacceptable TLD .space /\.stream$/ 510 Denied: Unacceptable TLD .stream /\.tech$/ 510 Denied: Unacceptable TLD .tech /\.top$/ 510 Denied: Unacceptable TLD .top /\.trade$/ 510 Denied: Unacceptable TLD .trade /\.vip$/ 510 Denied: Unacceptable TLD .vip /\.website$/ 510 Denied: Unacceptable TLD .website /\.win$/ 510 Denied: Unacceptable TLD .win /\.zone$/ 510 Denied: Unacceptable TLD .zone
Re: Mailq timestamps in localtime rather than UTC
Pedro David Marco: > Thanks Wietse.. > The? output is this:?? > # date ; env - dateWed Oct 23 21:22:20 CEST 2019Wed Oct 23 21:22:20 CEST 2019# > It is actual valid localtime...? > Thanks again, > Pedro. Can you run this AS A NON-ROOT USER? On the same machine that runs Postfix? The Postfix mailq command calls the postqueue command, which deletes most of its environment (similar to "env -") before calling the same standard library time conversion functions that are also used by the date command. I suspect the discreoancy is caused by environment or permission errors. Wietse
Re: block 'new style' TLDs ?
* li...@sbt.net.au: > what's the best way to block that, block entire '*.best' ? > how and where ? See http://www.postfix.org/ADDRESS_VERIFICATION_README.html . You can for example use /\.best$/ REJECT in a PCRE style sender access file to match envelope sender addresses. -Ralph
Re: Problem with new installation
On 23 Oct 2019, at 14:33, Steve Matzura wrote: [...] On a whim, I change the DNS record for mail from A to CNAME. That's a weird and dangerous whim. Hostnames that are used as the value for MX records MUST have A records and hence MUST NOT have CNAME records. The CNAME *MIGHT* work if done correctly for *SOME* sending MTAs, but when it breaks (and it *WILL*) you will need to fix it. Also, you did it wrong: $ host theglobalvoice.info theglobalvoice.info has address 95.142.174.193 theglobalvoice.info mail is handled by 10 mail.theglobalvoice.info. $ host mail.theglobalvoice.info Host mail.theglobalvoice.info not found: 3(NXDOMAIN) $ host -t cname mail.theglobalvoice.info mail.theglobalvoice.info is an alias for theglobalvoice.info.theglobalvoice.info. That indicates a common error made when specifying a hostname value of a record in a BIND zone file. HOWEVER: do not just fix the CNAME record, follow the RFCs and use an A record. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Problem with new installation
On 23 Oct 2019, at 12:33, Steve Matzura wrote: > I change the DNS record for mail from A to CNAME Don’t do that. https://tools.ietf.org/html/rfc2181 The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR. (An A or record is required) -- And, while it was regarded as pretty good evidence of criminality to be living in a slum, for some reason owning a whole street of them merely got you invited to the very best social occasions.
Re: Mailq timestamps in localtime rather than UTC
Thanks Wietse.. The output is this: # date ; env - dateWed Oct 23 21:22:20 CEST 2019Wed Oct 23 21:22:20 CEST 2019# It is actual valid localtime... Thanks again, Pedro. On Wednesday, October 23, 2019, 3:56:51 PM GMT+2, Wietse Venema wrote: Pedro David Marco: > Hi, > my Postfix 3.1.12 mailq command is showing timestamps in UTC... is it > possible to have them in localtime? > > It is not chrooted and /etc/localtime is correct. What is the output from: date ; env - date I'm asking this, because the date conversion happens in the postqueue program, which has no chroot option as it is not configured in master.cf. Wietse
Re: Problem with new installation
Things are definitely getting better, but not enough to make eighteen users happy yet. The manual granting of privileges in MySQL stopped the virtual alias errors entirely. More syslog checking revealed I did not have policyd-spf installed. I took care of that, but neglected to comment out the "TEST=1" line, so while it's running now, I don't know how to restart it to make sure that change propagates. The Milter error still puzzles. Looking into it more elsewhere as recommended. On a whim, I change the DNS record for mail from A to CNAME. No worries, the MX record was untouched. Now, when someone tries to send mail, they're getting 554's and/or 5.7.1's about relays. I read an article at https://bobcares.com/blog/554-5-7-1-relay-access-denied/ but don't know what to change to affect this. On 10/23/2019 11:23 AM, Noel Jones wrote: On 10/23/2019 8:27 AM, Steve Matzura wrote: I've narrowed my problems down to three. Two may be related. 1. Virtual alias table lookup failure: syslog is full of pairs of entries like these: Oct 23 13:03:06 theglobalvoice postfix/trivial-rewrite[23647]: warning: virtual_alias_domains: proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf: table lookup problem Oct 23 13:03:06 theglobalvoice postfix/trivial-rewrite[23647]: warning: virtual_alias_domains lookup failure Your mysql service isn't talking to postfix. Hopefully the mysql logs show more information, since that's what's not working. The fix for this probably isn't in the postfix config. Maybe mysql isn't running, or isn't working properly, or is being blocked by some system security software -- all postfix knows is that it doesn't answer queries. You can test table lookups with the postmap command, but if mysql is broken you'll need to use mysql tools for further debugging. I can't help with that. Postfix will not receive mail until you fix this error. 2. Milter service: Oct 23 13:08:03 theglobalvoice postfix/pickup[23600]: F41BC605E8: uid=1000 from= Oct 23 13:08:03 theglobalvoice postfix/cleanup[23702]: warning: connect to Milter service inet:localhost:8891: Connection refused Oct 23 13:08:03 theglobalvoice postfix/cleanup[23702]: F41BC605E8: message-id=<20191023130802.f41bc60...@mail.theglobalvoice.info> The milter service is not running, or not on the expected port number, or being blocked by a firewall or system security software. Other than maybe the wrong port, the other problems can't be fixed inside postfix. See the opendkim list for tips on debugging the milter. Or maybe your system doesn't resolve "localhost" to the expected IP; try using an IP literal instead. Postfix will not receive mail until you fix this error. 3. SMTP: Postfix will not receive mail until you fix the above errors.
Re: Rewrite From header from old to new style
On Wed, 23 Oct 2019 at 16:54, Maggie Q Roth wrote: > Hi I am newbie on technology sorry. > Do you know how I setup gmail to forward to a group of other emails? From > their webmail I can setup the only one. Will postfix do this stuff? > Maggie > This is not really a postfix question, you've posted it as an answer to an existing thread, and you've top-posted. But no matter: at the time of writing there are instructions for your requirement at https://www.makeuseof.com/tag/how-to-auto-forward-emails-to-multiple-addresses-in-gmail/. Postfix can do this and more but it may be overkill for what you are trying to achieve.
Re: Rewrite From header from old to new style
Hi I am newbie on technology sorry. Do you know how I setup gmail to forward to a group of other emails? From their webmail I can setup the only one. Will postfix do this stuff? Maggie > > On Tue, 22 Oct 2019 at 17:24, Dominic Raferd > wrote: > >> On Tue, 22 Oct 2019 at 17:05, Wietse Venema wrote: >> > >> > Noel Jones: >> > > On 10/22/2019 10:27 AM, Dominic Raferd wrote: >> > > > On Tue, 22 Oct 2019 at 16:18, Noel Jones >> wrote: >> > > >> ... >> > > >>> I am using postfix 3.3. Apart from cron, the only other local >> source >> > > >>> of such old-style headers that I can find is postfix itself: >> > > >>> e.g. From: mailer-dae...@streamingbats.co.uk (Mail Delivery >> System) >> > > >>> - maybe more recent postfix releases use the new style? >> > > >>> >> > > >> >> > > >> >> > > >> http://www.postfix.org/postconf.5.html#header_from_format >> > > > >> > > > Thanks Noel but I am using that (default) setting already: >> > > > # postconf header_from_format >> > > > header_from_format = standard >> > > > >> > > > I find the same behaviour in postfix 3.3.0 and 3.3.2. >> > > > >> > > >> > > >> > > Then whatever is generating the mail uses the obsolete format. You >> > > can use a header_checks IGNORE action to remove the offending >> > > header, and postfix will add it back. >> > >> > That is a better suggestion than using header_checks. However this >> > works only for /usr/bin/sendmail submission. >> >> I will try this, thanks. but it still seems to me that local >> double-bounce messages, which surely originate from Postfix, are using >> the legacy From header. I have put a (lightly obfuscated and >> shortened) example at https://pastebin.com/mVqGjAn2 which was >> generated while the server's internet connection was down - note the >> From: header. >> > > I can confirm that Noel's suggestion (using IGNORE in header_checks) works > - this corrects the 'From' header in messages from the local Cron Daemon > from the 'obsolete' to the new 'standard' format. Thank you. > > However I think double-bounce messages in Postfix 3.3 do not observe the > header_from_format > setting and instead use the 'obsolete' format. >
Re: Rewrite From header from old to new style
On Tue, 22 Oct 2019 at 17:24, Dominic Raferd wrote: > On Tue, 22 Oct 2019 at 17:05, Wietse Venema wrote: > > > > Noel Jones: > > > On 10/22/2019 10:27 AM, Dominic Raferd wrote: > > > > On Tue, 22 Oct 2019 at 16:18, Noel Jones > wrote: > > > >> ... > > > >>> I am using postfix 3.3. Apart from cron, the only other local > source > > > >>> of such old-style headers that I can find is postfix itself: > > > >>> e.g. From: mailer-dae...@streamingbats.co.uk (Mail Delivery > System) > > > >>> - maybe more recent postfix releases use the new style? > > > >>> > > > >> > > > >> > > > >> http://www.postfix.org/postconf.5.html#header_from_format > > > > > > > > Thanks Noel but I am using that (default) setting already: > > > > # postconf header_from_format > > > > header_from_format = standard > > > > > > > > I find the same behaviour in postfix 3.3.0 and 3.3.2. > > > > > > > > > > > > > Then whatever is generating the mail uses the obsolete format. You > > > can use a header_checks IGNORE action to remove the offending > > > header, and postfix will add it back. > > > > That is a better suggestion than using header_checks. However this > > works only for /usr/bin/sendmail submission. > > I will try this, thanks. but it still seems to me that local > double-bounce messages, which surely originate from Postfix, are using > the legacy From header. I have put a (lightly obfuscated and > shortened) example at https://pastebin.com/mVqGjAn2 which was > generated while the server's internet connection was down - note the > From: header. > I can confirm that Noel's suggestion (using IGNORE in header_checks) works - this corrects the 'From' header in messages from the local Cron Daemon from the 'obsolete' to the new 'standard' format. Thank you. However I think double-bounce messages in Postfix 3.3 do not observe the header_from_format setting and instead use the 'obsolete' format.
running a content_filter upon reinjection of a message with sendmail command
Here's what I want to do: 1. Email is received for an address I have set to forward emails, let's call it forw...@example.com. 2. Postfix pipes the email through a command postforward, which in turn runs the email through postsrsd, to make spf and such validate (especially when forwarding to an email address I don't host). 3. Postforward reinjects the email with sendmail, now with a return_path of @srs.example.org. 4. All of this works up to this point, but what I want to do next is send emails through to a dkim signing program, to sign emails from srs.example.org so that the dkim signature validates as well. Right now I'm trying to use dkimproxy as a content filter which is set to sign all messages from srs.example.org, but it seems that the cleanup daemon doesn't run on reinjected mails. I'm assuming there's a good reason for this, but it means that emails reinjected with postforward aren't going to processed by... just about anything as far as I can tell, so I can't get it to sign them. Output of postconf -n: alias_database = $alias_maps alias_maps = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases broken_sasl_auth_clients = yes command_directory = /usr/bin compatibility_level = 2 content_filter = dkim:127.0.0.1:10025 daemon_directory = /usr/lib/postfix/bin data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 dkim_destination_recipient_limit = 1 html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 5120 meta_directory = /etc/postfix milter_protocol = 6 mydestination = $myhostname, localhost, srs.mwtd.net myhostname = mtmail.mwtd.net mynetworks = 184.164.76.226/32, [2001:470:1f19:6ab::2]/128, 127.0.0.0/8, [::1]/128 mynetworks_style = host newaliases_path = /usr/bin/newaliases non_smtpd_milters = inet:127.0.0.1:8891 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix recipient_canonical_classes = envelope_recipient,header_recipient recipient_canonical_maps = tcp:127.0.0.1:10002 recipient_delimiter = + relay_domains = todo.2mb.codes, lists.2mb.codes, $mydestination sample_directory = /etc/postfix sender_dependent_default_transport_maps = pcre:/etc/postfix/sender_relay sendmail_path = /usr/bin/sendmail setgid_group = postdrop shlib_directory = /usr/lib/postfix smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sender_dependent_authentication = yes smtp_use_tls = no smtpd_delay_reject = yes smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893, inet:127.0.0.1:8892 smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_unauth_pipelining, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, check_policy_service inet:127.0.0.1:10030 smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_tls_CAfile = /etc/letsencrypt/live/mtmail.mwtd.net/chain.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/mtmail.mwtd.net/cert.pem smtpd_tls_dh1024_param_file = /etc/courier-imap/dhp4096.pem smtpd_tls_key_file = /etc/letsencrypt/live/mtmail.mwtd.net/privkey.pem smtpd_tls_security_level = may transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_domains = proxy:mysql:/etc/postfix/mysql_virtual_alias_domains.cf, lists.kallistimud.com, lists.legendsofkallisti.com, forwardme.email, am.forwardme.email, meowymail.com, forward.mwtd.net virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, hash:/var/lib/mailman/data/virtual-mailman, hash:/etc/postfix/virtual pcre:/etc/postfix/lists virtual_gid_maps = static:5000 virtual_mailbox_base = /home/vmail virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf, bounce.forwardme.email virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf, hash:/etc/postfix/bounce-domains virtual_minimum_uid = 100 virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_uid_maps = static:5000 Non comment lines in master.cf: smtp inet n - n - - smtpd -o content_filter=spamassassin submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions=permit_sasl_authenticated,permit_mynetworks,reject -o milter_macro_daemon_name=ORIGINATING 465 inet n - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o
Re: Problem with new installation
On 10/23/2019 8:27 AM, Steve Matzura wrote: I've narrowed my problems down to three. Two may be related. 1. Virtual alias table lookup failure: syslog is full of pairs of entries like these: Oct 23 13:03:06 theglobalvoice postfix/trivial-rewrite[23647]: warning: virtual_alias_domains: proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf: table lookup problem Oct 23 13:03:06 theglobalvoice postfix/trivial-rewrite[23647]: warning: virtual_alias_domains lookup failure Your mysql service isn't talking to postfix. Hopefully the mysql logs show more information, since that's what's not working. The fix for this probably isn't in the postfix config. Maybe mysql isn't running, or isn't working properly, or is being blocked by some system security software -- all postfix knows is that it doesn't answer queries. You can test table lookups with the postmap command, but if mysql is broken you'll need to use mysql tools for further debugging. I can't help with that. Postfix will not receive mail until you fix this error. 2. Milter service: Oct 23 13:08:03 theglobalvoice postfix/pickup[23600]: F41BC605E8: uid=1000 from= Oct 23 13:08:03 theglobalvoice postfix/cleanup[23702]: warning: connect to Milter service inet:localhost:8891: Connection refused Oct 23 13:08:03 theglobalvoice postfix/cleanup[23702]: F41BC605E8: message-id=<20191023130802.f41bc60...@mail.theglobalvoice.info> The milter service is not running, or not on the expected port number, or being blocked by a firewall or system security software. Other than maybe the wrong port, the other problems can't be fixed inside postfix. See the opendkim list for tips on debugging the milter. Or maybe your system doesn't resolve "localhost" to the expected IP; try using an IP literal instead. Postfix will not receive mail until you fix this error. 3. SMTP: Postfix will not receive mail until you fix the above errors. -- Noel Jones
Re: Replace semicolon in recipient list
luc...@dds.nl: > > So, you could rewrite the "To:" list into "," separated. > > That sounds like what I am looking for, thanks! > How do I do that? I did not get it to work with a REPLACE in the > header_checks... header_checks are based on first-match-wins, so you would need different regexps for different numbers of ' ;', with the longest match first, for example: - one pattern+result for To: headers with 10 ';' - one pattern+result for To: headers with 9 ';' .. - one pattern+result for To: headers with 1 ';' Only one of these rules will match (Postfix header_checks are not recursive, for safety reasons). Another possibility is to use smtpd_proxy_filter with a little smtpprox script that copies SMTP commands from Postfix to Postfix, while munging some headers on the fly. But this requires careful code to handle multiline headers correctly, something that header_checks already does. Good luck with parsing RFC5322 address syntax. Wietse
Re: Mailq timestamps in localtime rather than UTC
Pedro David Marco: > Hi, > my Postfix 3.1.12 mailq command is showing timestamps in UTC... is it > possible to have them in localtime? > > It is not chrooted and /etc/localtime is correct. What is the output from: date ; env - date I'm asking this, because the date conversion happens in the postqueue program, which has no chroot option as it is not configured in master.cf. Wietse
Re: Problem with new installation
I've narrowed my problems down to three. Two may be related.
1. Virtual alias table lookup failure:
syslog is full of pairs of entries like these:
Oct 23 13:03:06 theglobalvoice postfix/trivial-rewrite[23647]: warning:
virtual_alias_domains:
proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf: table lookup problem
Oct 23 13:03:06 theglobalvoice postfix/trivial-rewrite[23647]: warning:
virtual_alias_domains lookup failure
Here's mysql_virtual_alias_maps.cf, password redacted:
user = postfix
password = {redacted}
hosts = localhost
dbname = postfix
table = alias
select_field = goto
where_field = address
2. Milter service:
Oct 23 13:08:03 theglobalvoice postfix/pickup[23600]: F41BC605E8:
uid=1000 from=
Oct 23 13:08:03 theglobalvoice postfix/cleanup[23702]: warning: connect
to Milter service inet:localhost:8891: Connection refused
Oct 23 13:08:03 theglobalvoice postfix/cleanup[23702]: F41BC605E8:
message-id=<20191023130802.f41bc60...@mail.theglobalvoice.info>
I installed opendkim and opendkim-tools. This is one of probably many
holes I have in my knowledge of how mail security works these days, as I
remember doing none of this in 2016, or the person who did it for us
failed to communicate it when he was done. So much for free consulting.
3. SMTP:
Oct 23 13:18:03 theglobalvoice postfix/smtpd[24095]: lost connection
after RCPT from web01.groups.io[66.175.222.12]
Oct 23 13:18:03 theglobalvoice postfix/smtpd[24095]: disconnect from
web01.groups.io[66.175.222.12] ehlo=2 starttls=1 mail=1 rcpt=0/1
commands=4/5
Oct 23 13:18:03 theglobalvoice postfix/smtpd[24195]: lost connection
after RCPT from web01.groups.io[66.175.222.12]
Oct 23 13:18:03 theglobalvoice postfix/smtpd[24195]: disconnect from
web01.groups.io[66.175.222.12] ehlo=2 starttls=1 mail=1 rcpt=0/1
commands=4/5
Oct 23 13:18:17 theglobalvoice postfix/smtpd[24095]: connect from
web01.groups.io[66.175.222.12]
Oct 23 13:18:18 theglobalvoice postfix/smtpd[24095]: NOQUEUE: reject:
RCPT from web01.groups.io[66.175.222.12]: 451 4.3.0
: Temporary lookup failure;
from=
to= proto=ESMTP helo=
I don't know even where to start with this one. Time to go back to
school I think.
On 10/22/2019 7:10 PM, Steve Matzura wrote:
Thanks, Noel. Very helpful. MySQL is definitely installed and working,
but I don't know about Milter, as it was set up by someone else who
didn't quite do well by me in educating me in the find points of
Postfix management, which is why I am where I am today. I'll get on
that and report back.
On 10/22/2019 3:46 PM, Noel Jones wrote:
On 10/22/2019 1:58 PM, Steve Matzura wrote:
I am running a copy of configurations from a running version 2
installation from Ubuntu 14.04, now alive as version 3 on Ubuntu 18.04.
I thought I'd be slick and port over all the user mailbox
directories in /var/mail/vmail, all the customized .cf's, and the
MySQL database. Everything ported over nicely, Postfix runs in
backward compatibility mode, but for every mail message, I get this
in syslog:
Oct 22 18:51:36 tgvprod postfix/pickup[1114]: 852EB604E4: uid=1000
from=
Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning: connect to
Milter service inet:localhost:8891: Connection refused
This usually means the milter service isn't started, or not
installed. Or maybe the firewall preventing connections to the milter.
Did you install the milter from the other machine and copy its
config? Ditto firewall config?
Test until you get the milter working. The default value
milter_default_action=tempfail will prevent postfix from receiving
mail until this is fixed.
Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning:
proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf lookup error
for "tgvpadmin@tgvprod"
maybe your sql service isn't started, or not installed.
Did you install sql and copy the sql config files from the old machine?
Test until you get sql queries working. Generally it's easier to
start with hash: files before adding the complexity of a database.
To prevent losing mail, postfix will tempfail all mail when there's a
map lookup error.
-- Noel Jones
Re: Replace semicolon in recipient list
luc...@dds.nl: > Hello Group, > > I have configured Postfix as a relay to forward all messages to the AWS > SES mail service. > > One sending application is sending mail with a From: header containing a > semicolon-separated list of addresses. This is not according to the > standard (https://tools.ietf.org/html/rfc2822#section-3.6.3) and is > rejected by SES: > status=bounced (host email-smtp.eu-west-1.amazonaws.com[52.215.26.159] > said: 554 Transaction failed: Illegal semicolon, not in group (in reply > to end of DATA command)) > > Unfortunately I have little influence on the sending application and it > is not easy to correct this erratic behavior. > > To solve this I was looking for a REPLACE in the header_checks but I did > not find a way to replace the original header with a modified version of > itself (i.e., the original string with all semicolons replaced by > commas). > > Is there a solution to replace semicolons with commas in the To: header > of incoming mail? > Is it possible to avoid using a milter for this purpose? Why not extract the sender from the garbage, and output that instead? /^From: garbage (sender) garbage/ REPLACE From: $1 Wietse
Re: Replace semicolon in recipient list
on 2019/10/23 16:48, luc...@dds.nl wrote: So, you could rewrite the "To:" list into "," separated. That sounds like what I am looking for, thanks! How do I do that? I did not get it to work with a REPLACE in the header_checks... I saw postfix has a address rewrite guide you may want to check with. http://www.postfix.org/ADDRESS_REWRITING_README.html regards.
Re: Replace semicolon in recipient list
So, you could rewrite the "To:" list into "," separated. That sounds like what I am looking for, thanks! How do I do that? I did not get it to work with a REPLACE in the header_checks...
Re: Replace semicolon in recipient list
on 2019/10/23 16:40, luc...@dds.nl wrote: I was just curious, why the From addr is a list of addresses? Isn't from just a single address? My bad - I meant to say the "To:" header! So, you could rewrite the "To:" list into "," separated. regards.
Re: Replace semicolon in recipient list
I was just curious, why the From addr is a list of addresses? Isn't from just a single address? My bad - I meant to say the "To:" header! Thanks
Re: Replace semicolon in recipient list
Hi on 2019/10/23 16:27, luc...@dds.nl wrote: One sending application is sending mail with a From: header containing a semicolon-separated list of addresses. This is not according to the standard (https://tools.ietf.org/html/rfc2822#section-3.6.3) and is rejected by SES: I was just curious, why the From addr is a list of addresses? Isn't from just a single address? regards.
Replace semicolon in recipient list
Hello Group, I have configured Postfix as a relay to forward all messages to the AWS SES mail service. One sending application is sending mail with a From: header containing a semicolon-separated list of addresses. This is not according to the standard (https://tools.ietf.org/html/rfc2822#section-3.6.3) and is rejected by SES: status=bounced (host email-smtp.eu-west-1.amazonaws.com[52.215.26.159] said: 554 Transaction failed: Illegal semicolon, not in group (in reply to end of DATA command)) Unfortunately I have little influence on the sending application and it is not easy to correct this erratic behavior. To solve this I was looking for a REPLACE in the header_checks but I did not find a way to replace the original header with a modified version of itself (i.e., the original string with all semicolons replaced by commas). Is there a solution to replace semicolons with commas in the To: header of incoming mail? Is it possible to avoid using a milter for this purpose? Kind regards, Lucas
Re: about MX hosts
> On Oct 23, 2019, at 6:19 AM, Wesley Peng wrote: > > I saw my ESP has two MX records pointing to just the same host. > > rambler.ru. 21 IN MX 5 inmx.rambler.ru. > rambler.ru. 21 IN MX 10 inmx.rambler.ru. > > Does this have any value inprovement? Unlikely, but perhaps some DNS provider *requires* two records, and this is how they work around it. -- Viktor.
