Solved Sendmail seems to ignore /etc/aliases even after newaliases

That's the source (From:) address, yes. But that's mostly irrelevant.


So it should be pretty much default. Could you, just to rule out any issues here, remove the files named as the hostname and run:
Code:
cd /etc/mail/
make
make install
make restart
Hopefully that will make sure everything is set back to the default.


It does. But rewriting source or destination domains (or users) could potentially cause weird loops, which might be the case here.
What I mean with the initial address is that before anything else is processed, the mail to root would go to root@r710.domain.tld. Then /etc/aliases kicks in.

Now:

Code:
root@r710:~ # cd /etc/mail
root@r710:/etc/mail # ls -lah
total 278
drwxr-xr-x   3 root  wheel    19B Mar 25 12:23 .
drwxr-xr-x  25 root  wheel   119B Mar 25 11:56 ..
-rw-r--r--   1 root  wheel   6.7K Nov  1 05:32 Makefile
-rw-r--r--   1 root  wheel   2.8K Nov  1 05:32 README
-rw-r--r--   1 root  wheel   632B Nov  1 05:32 access.sample
-rw-r--r--   1 root  wheel   1.7K Mar 21 09:50 aliases
-rw-r-----   1 root  wheel   128K Mar 21 09:50 aliases.db
drwxr-xr-x   2 root  wheel     6B Mar 18 11:17 certs
-rw-r--r--   1 root  wheel    57K Nov  1 05:32 freebsd.cf
-rw-r--r--   1 root  wheel   4.4K Nov  1 05:32 freebsd.mc
-r--r--r--   1 root  wheel    40K Nov  1 05:32 freebsd.submit.cf
-r--r--r--   1 root  wheel   896B Nov  1 05:32 freebsd.submit.mc
-r--r--r--   1 root  wheel   5.5K Nov  1 05:32 helpfile
-rw-r--r--   1 root  wheel   364B Nov  1 05:32 mailer.conf
-rw-r--r--   1 root  wheel   248B Nov  1 05:32 mailertable.sample
-rw-r--r--   1 root  wheel    57K Mar 25 12:23 sendmail.cf
-rw-r--r--   1 root  wheel    57K Mar 20 07:04 sendmail.cf~
-r--r--r--   1 root  wheel    40K Nov  1 05:32 submit.cf
-rw-r--r--   1 root  wheel   574B Nov  1 05:32 virtusertable.sample

No files named r710 found here. Therefore:

Code:
root@r710:/etc/mail # make
cp -f freebsd.mc r710.domain.tld.mc
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/   /usr/share/sendmail/cf/m4/cf.m4 r710.domain.tld.mc > r710.domain.tld.cf
cp -f freebsd.submit.mc r710.domain.tld.submit.mc
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/   /usr/share/sendmail/cf/m4/cf.m4 r710.domain.tld.submit.mc > r710.domain.tld.submit.cf
root@r710:/etc/mail # make install
install -m 444 r710.domain.tld.cf /etc/mail/sendmail.cf
install -m 444 r710.domain.tld.submit.cf /etc/mail/submit.cf
root@r710:/etc/mail # make restart
Restarting: sendmail sendmail-clientmqueue.
root@r710:/etc/mail #
 
No files named r710 found here
No, but I do spot a backup file of sendmail.cf. Which suggests it's been edited at one point. That's fine actually, the make etc. should have restored it to its original state, as can be seen in your output.

Try testing it with mailx root, that test mail should be forwarded to the address set in aliases.
 
root@r710:/etc/mail # mailx root
Code:
Subject: Test message 666
Dear Santa
Yours Truly
.
EOT
root@r710:/etc/mail # tail /var/log/maillog
Mar 25 17:18:47 r710 sm-mta[30376]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 17:18:48 r710 sm-mta[30376]: 02PGIlX0030376: from=<root@r710.domain.tld>, size=375, class=0, nrcpts=1, msgid=<202003251618.02PGIlBc030375@r710.domain.tld>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
Mar 25 17:18:48 r710 sendmail[30375]: 02PGIlBc030375: to=root, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30059, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PGIlX0030376 Message accepted for delivery)
Mar 25 17:18:48 r710 sm-mta[30378]: STARTTLS=client, relay=mxavas.forpsi.com., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: to=<root@r710.domain.tld>, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=30375, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: 02PGInWx030378: DSN: User unknown
Mar 25 17:18:50 r710 sm-mta[30378]: 02PGInWx030378: to=<root@r710.domain.tld>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=31399, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
Mar 25 17:18:51 r710 sm-mta[30378]: 02PGInWx030378: 02PGInX0030378: return to sender: User unknown
Mar 25 17:18:51 r710 sm-mta[30378]: STARTTLS=client, relay=slow.domain.tld., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 17:18:51 r710 sm-mta[30378]: 02PGInX0030378: to=mikko@slow.domain.tld, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=32423, relay=slow.domain.tld. [90.176.149.141], dsn=2.0.0, stat=Sent (02PGIpVW130724 Message accepted for delivery)
 
root@r710:/etc/mail # mailx root
Code:
Subject: Test message 666
Dear Santa
Yours Truly
.
EOT
root@r710:/etc/mail # tail /var/log/maillog
Mar 25 17:18:47 r710 sm-mta[30376]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 17:18:48 r710 sm-mta[30376]: 02PGIlX0030376: from=<root@r710.domain.tld>, size=375, class=0, nrcpts=1, msgid=<202003251618.02PGIlBc030375@r710.domain.tld>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
Mar 25 17:18:48 r710 sendmail[30375]: 02PGIlBc030375: to=root, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30059, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PGIlX0030376 Message accepted for delivery)
Mar 25 17:18:48 r710 sm-mta[30378]: STARTTLS=client, relay=mxavas.forpsi.com., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: to=<root@r710.domain.tld>, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=30375, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: 02PGInWx030378: DSN: User unknown
Mar 25 17:18:50 r710 sm-mta[30378]: 02PGInWx030378: to=<root@r710.domain.tld>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=31399, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
Mar 25 17:18:51 r710 sm-mta[30378]: 02PGInWx030378: 02PGInX0030378: return to sender: User unknown
Mar 25 17:18:51 r710 sm-mta[30378]: STARTTLS=client, relay=slow.domain.tld., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 17:18:51 r710 sm-mta[30378]: 02PGInX0030378: to=mikko@slow.domain.tld, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=32423, relay=slow.domain.tld. [90.176.149.141], dsn=2.0.0, stat=Sent (02PGIpVW130724 Message accepted for delivery)
In addition, the bouncer:
Code:
The original message was received at Wed, 25 Mar 2020 17:18:49 +0100 (CET)
from localhost
with id 02PGInWx030378

----- The following addresses had permanent fatal errors -----
<root@r710.domain.tld>
(reason: 550 5.1.1 H8jwjhUuQd2rjH8jxj11Ff Sorry, no user here by that name)

----- Transcript of session follows -----
... while talking to mxavas.forpsi.com.:

[QUOTE][QUOTE][QUOTE]RCPT To:<root@domain.tld>
[/QUOTE][/QUOTE][/QUOTE]
<<< 550 5.1.1 H8jwjhUuQd2rjH8jxj11Ff Sorry, no user here by that name
550 5.1.1 <root@r710.domain.tld>... User unknown

[QUOTE][QUOTE][QUOTE]DATA
[/QUOTE][/QUOTE][/QUOTE]
<<< 503 5.5.0 need RCPT before DATA
 
Submitting works:
Code:
Mar 25 17:18:48 r710 sendmail[30375]: 02PGIlBc030375: to=root, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30059, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PGIlX0030376 Message accepted for delivery)
This one I don't understand though:
Code:
Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: to=<root@r710.domain.tld>, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=30375, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
That r710.domain.tld is the machine's hostname right? Why is it trying to relay it to mxavas.forpsi.com?
 
I didn't see you actually ran the command to rebuild the database ..

sendmail -bi

Mar 25 17:18:48 r710 sendmail[30375]: 02PGIlBc030375: to=root, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30059, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PGIlX0030376 Message accepted for delivery)
this is the message been accepted to the mta for processing .. in this case its basically saying it accepted a message from the system 220 ok aka its applying transport and internal rules ..

the result of those rules is resolving to this address..

Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: to=<root@r710.domain.tld>, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=30375, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown

if this 81.2 address IS correct .. then that mta does NOT have an account for the r710 user (or the sendmail -bi comamnd was not run and it has not updated the valid userlist)

if the address is NOT correct

it's either a dns problem .. where r710 is resolving incorrectly to this 81.2 address..
or there is a transport rule redirecting mail from r710 to the 81.2 ip address.
 
Submitting works:
This one I don't understand though:
Code:
Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: to=<root@r710.domain.tld>, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=30375, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
That r710.domain.tld is the machine's hostname right? Why is it trying to relay it to mxavas.forpsi.com?
The machine's non-qualified hostname is r710. hostname states that the machine's fully qualified hostname is r710.domain.tld. The MX for domain.tld is mxavas.forpsi.com.

However, the address I aliased root to is mikko@domain.tld. Again, mxavas is the MX for domain.tld. What I don't understand is why mikko is changed back to root.
 
Take a step back, remove the address from aliases (don't forget to run newaliases). Let's try to get the mail delivered to root's own mailbox first, then we'll try the aliases again.
 
Take a step back, remove the address from aliases (don't forget to run newaliases). Let's try to get the mail delivered to root's own mailbox first, then we'll try the aliases again.
Not that this makes any sense to me anymore (the output from maillog). It is still trying to send it via Forpsi:
Code:
Mar 25 17:56:56 r710 sendmail[30580]: /etc/mail/aliases: 29 aliases, longest 10 bytes, 297 bytes total
Mar 25 17:57:03 r710 sendmail[30583]: 02PGv3VJ030583: from=root, size=34, class=0, nrcpts=1, msgid=<202003251657.02PGv3VJ030583@r710.domain.tld>, relay=root@localhost
Mar 25 17:57:03 r710 sendmail[30583]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 17:57:03 r710 sm-mta[30584]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 17:57:04 r710 sm-mta[30584]: 02PGv3Ux030584: from=<root@r710.domain.tld>, size=350, class=0, nrcpts=1, msgid=<202003251657.02PGv3VJ030583@r710.domain.tld>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
Mar 25 17:57:04 r710 sendmail[30583]: 02PGv3VJ030583: to=root, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30034, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PGv3Ux030584 Message accepted for delivery)
Mar 25 17:57:04 r710 sm-mta[30586]: STARTTLS=client, relay=mxavas.forpsi.com., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Mar 25 17:57:06 r710 sm-mta[30586]: 02PGv3Ux030584: to=<root@r710.domain.tld>, delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=30350, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
Mar 25 17:57:06 r710 sm-mta[30586]: 02PGv3Ux030584: 02PGv6Uw030586: DSN: User unknown
Mar 25 17:57:06 r710 sm-mta[30586]: 02PGv6Uw030586: to=<root@r710.domain.tld>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=31374, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
Mar 25 17:57:06 r710 sm-mta[30586]: 02PGv6Uw030586: 02PGv6Ux030586: return to sender: User unknown
Mar 25 17:57:06 r710 sm-mta[30586]: 02PGv6Ux030586: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=32398, relay=local, dsn=2.0.0, stat=Sent
 
However, the address I aliased root to is mikko@domain.tld. Again, mxavas is the MX for domain.tld. What I don't understand is why mikko is changed back to root.

Mar 25 17:18:48 r710 sendmail[30375]: 02PGIlBc030375: to=root, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30059, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PGIlX0030376 Message accepted for delivery)

the original message was received by the mta as message id 02PGIlBc030375. the outbound message after processing was assigned the id: 02PGIlX0030376

Mar 25 17:18:48 r710 sm-mta[30378]: STARTTLS=client, relay=mxavas.forpsi.com., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256

it tried to establish a tls connection to what sendmail thinks is the correct domain.. elay=mxavas.forpsi.com the message 02PGIlX0030376

Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: to=<root@r710.domain.tld>, delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=30375, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown

the original message was processed and split as 02PGIlX0030376 as per your policy to root@r710.domain.tld (hence the new message id 02PGIlX0030376). this is expected this delay=00:00:02, says it took the recipient mta a split second to respond with stat=User unknown

Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: 02PGInWx030378: DSN: User unknown

the recipient server responded with 02PGInWx030378: root@r710.domain.tld is user NOT known..

I would expect this when the address does not exist (or the recipient server does not understand the mail to: header)


RFC for email dictates (in short) that every time a message is sent, processed or recieved by an mta the headers are appended.. if changes are needed for what ever reason .. a new message id is created for each instance where the message is created..

for example.. postfix writes mail to disk .. it consists of an incoming mailq, a milter (or processing mta) and an backend mail queue.

everytime a message is received by the backen queue, sent to the milter and forwarded to the front sendmail queue .. there is a new message id created..

In the case of sendmail, there is no mail queue in the respect.. ALL processing is done on the message BEFORE it is sent.. however new message id's ARE generated when a milter changes / splits a message (aka rewriting headers) .. or when a recipient server responds .. in your case the server responded with a new message id..

email logs are generally confusing .. but if you follow the logic each line in the log can be traced .. you will aslays see something like MessageID. . process .. MessageID out (if needed) .. in the case of a normal email you will get both the in message id and a response id.. in this your getting 3 message id's becasue you have an original email, a split and a response
 
aka your message is been sent as the original user, your policy for sendmail is working .. sendmail thinks the result of its policy scan is to send a mesage split to root@r710.domain .. that resolves to 81.2.195.200. the domain is answering the request and telling your mta that the user you aliased the email to does not exist

to isolate the problem you need to verify what step of this process is not expected..

ie:
is the original user correct? (if not chances are theres a configuration issue with what ever originally generated the actual email

did sendmail run policy for that user correctly? (if not, there is a configuration issue with sendmail its self . could be a transport map, policy, an alias or similar)

should the result be to send the message to this domain? (same as above but its probally something like a user map or list rather than core configuration)

does this domain resolve to the correct ip address? ( if the domain is not correct then something in send mails transport is incorrectly associating the domain) else it is a dns problem, could be a dead/old record or bad cached record or similar..

how does the domain see the message its been sent .. (if you only see the original email address, then the split process did not happen properly, or it was trashed) this could be an issue with transport configuration.

(ie if you just run an alias, it's going to see the message differently than if you do a complete address re-write).

it's important to identify exactly what part of the process is NOT working as expected ..

assuming the ips are correct and all of the other information is correct

Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: 02PGInWx030378: DSN: User unknown

says with 100% certainty this problem is because the recipient server does not understand who this user is, nor can it deliver mail for this user.. to correct this issue you will need to either create rules for this email user/account .. or send the mail as a user that exists and already has rules to deal with the email
 
aka your message is been sent as the original user, your policy for sendmail is working .. sendmail thinks the result of its policy scan is to send a mesage split to root@r710.domain .. that resolves to 81.2.195.200. the domain is answering the request and telling your mta that the user you aliased the email to does not exist

to isolate the problem you need to verify what step of this process is not expected..

ie:
is the original user correct? (if not chances are theres a configuration issue with what ever originally generated the actual email

did sendmail run policy for that user correctly? (if not, there is a configuration issue with sendmail its self . could be a transport map, policy, an alias or similar)

should the result be to send the message to this domain? (same as above but its probally something like a user map or list rather than core configuration)

does this domain resolve to the correct ip address? ( if the domain is not correct then something in send mails transport is incorrectly associating the domain) else it is a dns problem, could be a dead/old record or bad cached record or similar..

how does the domain see the message its been sent .. (if you only see the original email address, then the split process did not happen properly, or it was trashed) this could be an issue with transport configuration.

(ie if you just run an alias, it's going to see the message differently than if you do a complete address re-write).

it's important to identify exactly what part of the process is NOT working as expected ..

assuming the ips are correct and all of the other information is correct

Mar 25 17:18:49 r710 sm-mta[30378]: 02PGIlX0030376: 02PGInWx030378: DSN: User unknown

says with 100% certainty this problem is because the recipient server does not understand who this user is, nor can it deliver mail for this user.. to correct this issue you will need to either create rules for this email user/account .. or send the mail as a user that exists and already has rules to deal with the email
Zader,

Could you please elaborate with more concise sentences and attempt to use terminology related to the components you are attempting to write about? Please elaborate what you mean with with sendmail running a policy scan, to begin with. You can then explain the concept of running an alias and continue with address rewrites.

Once you have worked your way up to the last paragraph, please read again what I have written before. This has nothing to do with the configuration of any imaginary mail client, the receiving mail exchanger, the certificates used between sendmail and the receiving mail exchanger, blocklists, quarantines, .forward files, message splitting or the other concepts you have introduced.

It has already been established that the receiving mail server rejects the mail because the recipient does not exist, and this is for the reason that the recipient does not exist. As to why sendmail is attempting to send e-mail to the wrong user, that is the issue here, and has been since the beginning of the thread.
 
here is a better question ..

why do you think sendmail is trying to send mail to the wrong user and what exactly is the user receiving?

according to the logs you posted, sendmail is doing exactly what its supposed to.

go create the user box on the server thats rejecting the mail .. what is delivered?
are you mistaking an NDR/BOUNCE mail as something else? 02PGInWx030378: DSN: User unknown
that is a return bounce/ndr email .. check the logs for that email.. what does it say?!
 
mta's only understand A records, MX records and TXT records such as spf dkim dmarc .. cname records should never be used for email.

sendmail -bp
Code:
                /var/spool/mqueue (3 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
m9TMLQHG012749     1103 Thu Oct 30 11:21 <apache@localhost.localdomain>
                 (host map: lookup (electrictoolbox.com): deferred)
                                         <test@electrictoolbox.com>
m9TMLRB9012751    37113 Thu Oct 30 11:21 <apache@localhost.localdomain>
                 (host map: lookup (electrictoolbox.com): deferred)
                                         <test@electrictoolbox.com>
m9TMLPcg012747   240451 Thu Oct 30 11:21 <apache@localhost.localdomain>
                 (host map: lookup (electrictoolbox.com): deferred)
                                         <test@electrictoolbox.com>
                Total requests: 3

mail that is deferred by default will remain in mail queues for 5 days .. however mail is continually retried, so if you make a change to dns the next time it is queued it would use the new changes.
 
sendmail -bt
Code:
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>
>3,0 root@r710.domain

what does it say?
 
Shall I try to send the e-mail to Santa or to the intended recipient?

You should not try to send mail at all. Instead you should look what exactly sendmail is going to do to the address if it were sent: sendmail -bv -d27.20 root

-bv just tests the address and tells where it would try to send it.
-d27 shows the alias expansions.
-d27.20 increases debug output to level 20.

Besides the 27, there are many other numbers showing debug information for the various parts of sendmail. Here is a list.
 
You should not try to send mail at all. Instead you should look what exactly sendmail is going to do to the address if it were sent: sendmail -bv -d27.20 root

-bv just tests the address and tells where it would try to send it.
-d27 shows the alias expansions.
-d27.20 increases debug output to level 20.

Besides the 27, there are many other numbers showing debug information for the various parts of sendmail. Here is a list.
Thank you.

At this point, it produces
Code:
setalias(/etc/mail/aliases)
  map implicit:Alias0 /etc/mail/aliases
alias(root)
aliaswait(implicit:/etc/mail/aliases)
root (, root) aliased to mikko@domain.tld
alias: QS_EXPANDED 0x800b27518=root:
        mailer 3 (local), host `'
        user `root', ruser `<null>'
        state=OK, next=0x0, alias 0x0, uid 0, gid 0
        flags=182<QPRIMARY,QPINGONFAILURE,QPINGONDELAY>
        owner=(none), home="(none)", fullname="(none)"
        orcpt="(none)", statmta=(none), status=(none)
        finalrcpt="RFC822; root@r710.domain.tld"
        rstatus="(none)"
        statdate=(none)
self_reference(mikko@domain.tld)
        ... no self ref
mikko@domain.tld... deliverable: mailer esmtp, host domain.tld., user mikko@domain.tld
and attempts delivery to the right recipient. What I have changed in the mean time was removing the *.domain.tld cname from the DNS records and adding a static reference to the sending computer's name to the name server in the internal network (edited /etc/hosts in the computer that, in the internal network, provides name services).

If I am reading the log correctly, it is failing now because the receiving MX does not like the domain from which the message claims to come, r710.domain.tld. Still checking this.
 
SOLVED. In addition to deleting the wildcard cname, I edited the local name server's hosts file and finally added an A record for the FreeBSD computer in the public DNS records. The A record points to the fixed IP address assigned to my connection. I then went on a ride on the exercise bike for a little over an hour and tried again. During that time, the new A record apparently took effect and the issue is now solved.

As SirDice correctly assumed, it was a hiccup with name resolution. Now there is no more hiccup. Thank you to everyone.
 
Back
Top