Problem with new installation

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with new installation

Steve Matzura
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=<tgvpadmin>
Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning: connect to
Milter service inet:localhost:8891: Connection refused
Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning:
proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf lookup error for
"tgvpadmin@tgvprod"


or this:


Oct 22 18:54:08 tgvprod postfix/smtpd[3174]: connect from
web01.groups.io[66.175.222.12]
Oct 22 18:54:09 tgvprod postfix/smtpd[3174]: NOQUEUE: reject: RCPT from
web01.groups.io[66.175.222.12]: 451 4.3.0
<[hidden email]>: Temporary lookup failure;
from=<[hidden email]>
to=<[hidden email]> proto=ESMTP helo=<web01.groups.io>
Oct 22 18:54:09 tgvprod postfix/smtpd[3174]: lost connection after RCPT
from web01.groups.io[66.175.222.12]
Oct 22 18:54:09 tgvprod postfix/smtpd[3174]: disconnect from
web01.groups.io[66.175.222.12] ehlo=2 starttls=1 mail=1 rcpt=0/1
commands=4/5

I'm thinking it's something common to both problems, but can't figure
what. Any assistance gratefully appreciated.

Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Noel Jones-2
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=<tgvpadmin>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Steve Matzura
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=<tgvpadmin>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Steve Matzura
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=<tgvpadmin>
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=<[hidden email]>


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
<[hidden email]>: Temporary lookup failure;
from=<[hidden email] >
to=<[hidden email]> proto=ESMTP helo=<web01.groups.io>


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=<tgvpadmin>
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Noel Jones-2
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=<tgvpadmin>
> 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=<[hidden email]>


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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Steve Matzura
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=<tgvpadmin>
>> 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=<[hidden email]>
>
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

@lbutlr
On 23 Oct 2019, at 12:33, Steve Matzura <[hidden email]> 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 AAAA 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.

Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Bill Cole-3
In reply to this post by Steve Matzura
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
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Steve Matzura
In reply to this post by @lbutlr
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 <[hidden email]> 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 AAAA record is required)
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Viktor Dukhovni
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.
Reply | Threaded
Open this post in threaded view
|

Re: Problem with new installation

Steve Matzura
In reply to this post by Bill Cole-3
I thought this was a directory ownership problem. /var/mail/vmail/...
was owned by dovenull:dovecot. In any previous Dovecot+Postfix
installation I've had, it's been owned by postfix:postfix. using chown
on this directory tree didn't fix the problem:


Oct 26 12:54:28 theglobalvoice postfix/local[8025]: 79FFA60A53:
to=<[hidden email]>, relay=local, delay=0.56,
delays=0.5/0.02/0/0.03, dsn=5.2.0, status=bounced (maildir delivery
failed: create maildir file
/var/mail/vmail/yourvoice/tmp/1572094468.P8025.theglobalvoice.info:
Permission denied)


On 10/23/2019 3:42 PM, Bill Cole wrote:

> 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.
>
>
>