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

I have root aliased in /etc/aliases as a normal e-mail address to my e-mail account. I have run newaliases(8). When the daily run output is sent out by e-mail, I expect that the system will attempt to deliver it to the address specified for root in /etc/aliases. Instead of that address, let it be called name@domain.tld, it is being sent to root@domain.tld. The result is that the MX at domain.tld says there is no user by the name of root there and bounces it back to the sender.

What am I missing or failing to do? How do I make root's e-mail go to where I expect it to go?
 
Check your /var/log/maillog. I have various machines all routing the periodic emails to a specific email address. No problems there. Perhaps you tried setting things in /etc/virtusertable that causes this "translation"?
 
Without showing us the actual line you used it's impossible to tell.

Keep in mind though that the actual file is /etc/mail/aliases, see also the manualpage you referenced.

(edit): Maybe a link got messed up?
 
ShelLuser:
The /etc/mail/aliases, which /etc/aliases is a link to, reads:
root@r710:~ # joe /etc/mail/aliases
...
Code:
# Pretty much everything else in this file points to "root", so
# you would do well in either reading root's mailbox or forwarding
# root's email from here.

root:   user@<anotherhostname.domain.tld>
...
For the sake of brevity, I deleted the header and lines following the root specification from the file, but they are unaltered from what was installed with the system. For the sake of keeping my e-mail address not disclosed, I have replaced the explicit address with a reference to it above.

On R710 (the FreeBSD computer), sendmail will then attempt delivery to root@<anotherhostname.domain.tld>.
 
Test 2: send mail with alpine to root. Root is expanded to root@r710.<domain.tld>. When sent out, it will generate this output in /var/log/maillog:

Code:
Mar 25 12:26:15 r710 sendmail[28850]: 02PBQF3b028850: from=<root@r710.<domain.tld>>, size=340, class=0, nrcpts=1, msgid=<alpine.BSF.2.21.99999.352.2003251226110.28849@r710.<domain.tld>>, proto=ESMTP, relay=root@localhost
Mar 25 12:26:15 r710 sendmail[28852]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 12:26:15 r710 sm-mta[28853]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 12:26:15 r710 sm-mta[28853]: 02PBQFND028853: from=<root@<domain.tld>>, size=538, class=0, nrcpts=1, msgid=<alpine.BSF.2.21.99999.352.2003251226110.28849@r710.<domain.tld>>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
Mar 25 12:26:15 r710 sendmail[28852]: 02PBQF3b028850: to=<root@r710.<domain.tld>>, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30340, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PBQFND028853 Message accepted for delivery)
Mar 25 12:26:16 r710 sm-mta[28855]: STARTTLS=client, relay=mxavas.forpsi.com., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Mar 25 12:26:17 r710 sm-mta[28855]: 02PBQFND028853: to=<root@<domain.tld>>, delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=30538, relay=mxavas.forpsi.com. [81.2.195.200], dsn=5.1.1, stat=User unknown
 
Check your /var/log/maillog. I have various machines all routing the periodic emails to a specific email address. No problems there. Perhaps you tried setting things in /etc/virtusertable that causes this "translation"?
Sorry, I did not see your reference to virtusertable. I seem to be not using it:

root@r710:~ # locate virtusertable

Code:
/etc/mail/virtusertable.sample
/usr/share/sendmail/cf/feature/virtusertable.m4
/usr/src/contrib/sendmail/cf/feature/virtusertable.m4
/usr/src/etc/mail/virtusertable.sample
/var/db/etcupdate/current/etc/mail/virtusertable.sample
 
What happens if you send an email from the command-line using mailx user@domain.tld?
 
What happens if you send an email from the command-line using mailx user@domain.tld?
The mail goes exactly where it should go.
Code:
Mar 25 12:37:35 r710 sendmail[28915]: 02PBbZaU028915: from=root, size=48, class=0, nrcpts=1, msgid=<202003251137.02PBbZaU028915@r710.<domain.tld>>, relay=root@localhost
Mar 25 12:37:35 r710 sendmail[28915]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 12:37:35 r710 sm-mta[28916]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 12:37:36 r710 sm-mta[28916]: 02PBbZ9E028916: from=<root@r710.<domain.tld>>, size=365, class=0, nrcpts=1, msgid=<202003251137.02PBbZaU028915@r710.<domain.tld>>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
Mar 25 12:37:36 r710 sendmail[28915]: 02PBbZaU028915: to=mikko@<slow.domain.tld>, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30048, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PBbZ9E028916 Message accepted for delivery)
Mar 25 12:37:36 r710 sm-mta[28918]: STARTTLS=client, relay=<slow.domain.tld>., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 12:37:36 r710 sm-mta[28918]: 02PBbZ9E028916: to=<mikko@<slow.domain.tld>>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=30365, relay=<slow.domain.tld>. [xx.xx.xx.xx], dsn=2.0.0, stat=Sent (02PBba12026746 Message accepted for delivery)
Mar 25 12:37:42 r710 sendmail[28921]: 02PBbgcU028921: from=root, size=43, class=0, nrcpts=1, msgid=<202003251137.02PBbgcU028921@r710.<domain.tld>>, relay=root@localhost
Mar 25 12:37:42 r710 sendmail[28921]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 12:37:42 r710 sm-mta[28922]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Mar 25 12:37:42 r710 sm-mta[28922]: 02PBbg75028922: from=<root@r710.<domain.tld>>, size=355, class=0, nrcpts=1, msgid=<202003251137.02PBbgcU028921@r710.<domain.tld>>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
Mar 25 12:37:42 r710 sendmail[28921]: 02PBbgcU028921: to=mikko@<domain.tld>, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30043, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (02PBbg75028922 Message accepted for delivery)
Mar 25 12:37:42 r710 sm-mta[28924]: STARTTLS=client, relay=mxavas.forpsi.com., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Mar 25 12:37:43 r710 sm-mta[28924]: 02PBbg75028922: to=<mikko@<domain.tld>>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30355, relay=mxavas.forpsi.com. [81.2.195.200], dsn=2.0.0, stat=Sent (H4LujgJ0id2rjH4Luj0UzB mail accepted for delivery)
root@r710:~ #
 
couple of things...

version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384

openssl validation is failing .. so it looks like the mail is been sent in clear .. if the recipient server does not allow that .. it may be dropping your mail for validation reasons.

try this:

openssl s_client -starttls smtp -connect smtp.gmail.com:587 -crlf -ign_eof

change :587 to the proper port .. 587/993/25 etc .. change smtp.gmail. ..

you should get something like this (if not compare it to the gmail example). you could see a self signed, expired or validation failure for incomplete certificate chain

Code:
CONNECTED(00000005)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = smtp.gmail.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=smtp.gmail.com
   i:/C=US/O=Google Trust Services/CN=GTS CA 1O1
1 s:/C=US/O=Google Trust Services/CN=GTS CA 1O1
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
--

Server certificate
-----BEGIN CERTIFICATE-----
MIIFijCCBHKgAwIBAgIRAKJoPu/IUAyiCAAAAAAyCnEwDQYJKoZIhvcNAQELBQAw
QjELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczET
---%<-----

-----END CERTIFICATE-----


subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=smtp.gmail.com
issuer=/C=US/O=Google Trust Services/CN=GTS CA 1O1
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 3451 bytes and written 316 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-CHACHA20-POLY1305
    Session-ID: B3A88954AAEE169A51A3D78E57FA9BBB88B6CD3B8FC6949ACE705B58803DD12
    Session-ID-ctx:
    Master-Key: 043A264144E0BFCA842769BF66F42047E8B341EBD7088C506B7D92E08F832677E8A40234A8E52516E46C37483D42C9F0

    TLS session ticket lifetime hint: 100800 (seconds)

    TLS session ticket:
    0000 - 01 1b b2 47 2f 10 ef 51-61 f7 76 6f f9 23 0f fb   ...G/..Qa.vo.#..
    0010 - 12 b1 24 4f 13 59 3c ab-f0 bb 9c 91 44 4d 61 76   ..$O.Y<.....DMav
    0020 - 3a a5 6c fb fb e2 13 0e-6b 08 26 5b e1 67 d7 77   :.l.....k.&[.g.w
    0030 - 79 ae 5e 29 da 58 e3 95-a7 45 0a dd bd 42 a1 fa   y.^).X...E...B..
    0040 - 73 36 64 49 c8 b6 92 61-71 95 c7 bc cb 92 aa 51   s6dI...aq......Q
    0050 - 8d 80 52 d9 cc 26 bf bc-2e 0a 20 8d 82 84 8b 12   ..R..&.... .....
    0060 - 2f 57 33 65 bd ad b5 b0-13 67 bd 8e 60 fe 0d 13   /W3e.....g..`...
    0070 - f4 07 15 f7 37 e8 bc 0b-89 a5 6c d4 64 3f ce de   ....7.....l.d?..
    0080 - be 37 fd 92 75 63 5c fd-da ac 96 34 14 31 8b b2   .7..uc\....4.1..
    0090 - 6f c5 29 74 1b 0a 8b 9b-19 22 82 c5 da da 52 cc   o.)t....."....R.
    00a0 - 15 43 42 f2 fd 59 fb b2-b4 16 55 b5 c1 9d a5 48   .CB..Y....U....H
    00b0 - 25 a0 3b e1 c9 19 2c a0-0f 77 b4 bc cb cc 49 69   %.;...,..w....Ii
    00c0 - 23 d9 50 d7 05 48 22 2c-4d eb ab bd 58 d6 99 90   #.P..H",M...X...
    00d0 - d8 82 f3 bb a1 20 73 0e-ef 0d 74 42 b8            ..... s...tB.

    Start Time: 1585147118
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
250 SMTPUTF8

if you make it to this part (250 SMTPUTF8) you can test sending an email

Code:
Helo localhost
Mail from: support@freebsd.org
Rcpt to: santa@northpole.com
DATA
Subject: test email
From: support@freebsd.org
ENTER MESSAGE
    (blank line)
.

you should see something like

message accepted xxxxxx delivered..

if any part of the test email fails, chances are the recipient server is doing user or message validation.. or it has sent a downstream lookahead request and the user was rejected.

this part
[81.2.195.200], dsn=5.1.1, stat=User unknown
tells me the recipient server does not know how to route your email .. by sending the mail manually via telnet / openssl you should be able to see that ..
 
if any part of the test email fails, chances are the recipient server is doing user or message validation.. or it has sent a downstream lookahead request and the user was rejected.

Thank you for the suggestion. However, the connection is accepted with port 25 and the certificate is processed OK. The problem is not with the certificate but with the fact that the daily output is being sent to the wrong recipient. The OS makes no attempt to use the address in /etc/aliases but uses some other address, instead. Therefore, the user IS rejected.

openssl s_client -starttls smtp -connect mxavas.forpsi.com:25 -crlf -ign_eof
Code:
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 2018
verify return:1
depth=0 CN = *.forpsi.com
verify return:1
---
Certificate chain
 0 s:CN = *.forpsi.com
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 2018
 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 2018
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFsDCCBJigAwIBAgIQAljVZqV6Wtxgn0kbMqwWljANBgkqhkiG9w0BAQsFADBe
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMR0wGwYDVQQDExRSYXBpZFNTTCBSU0EgQ0EgMjAxODAe
Fw0xOTA4MDgwMDAwMDBaFw0yMDEwMDYxMjAwMDBaMBcxFTATBgNVBAMMDCouZm9y
cHNpLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMEP/6LYkGWU
UuxDzuCN73X566LQ0Ld131i7IpnpNUJVQXAwkmNhyQznlxWM4x5ArqZLehN8Jla3
0fVHYkOb3BF3w0J1OHXSkMPDSZoXiRcUX7UQzHENsbM+bM9SY6FPgceoTIWhZKyk
RX9mGYim/WIcYWw83SPCUeB2XapGluC0vqswry/dIxF0QcMimv0Qon3+zPrf2pcl
BEIHN9rIkHjxXRMscffmOrFjH/ZMb2cUVob7Xmdn0gM4Gs4gMdq6YOfR4iEfSa3+
j5c1nVLSviv1VP3tLC6wf2peoqpb6yIHTc7zdi1Hscm3ACqMam7Psx9Him6acHg4
mCN3+aiNIUUCAwEAAaOCAq8wggKrMB8GA1UdIwQYMBaAFFPKF1n8a8ADIS8aruSq
qByCVtp1MB0GA1UdDgQWBBTfI5yt+Tikzxcf9Jtzrx/zCEkX6TAjBgNVHREEHDAa
ggwqLmZvcnBzaS5jb22CCmZvcnBzaS5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjA+BgNVHR8ENzA1MDOgMaAvhi1odHRw
Oi8vY2RwLnJhcGlkc3NsLmNvbS9SYXBpZFNTTFJTQUNBMjAxOC5jcmwwTAYDVR0g
BEUwQzA3BglghkgBhv1sAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGln
aWNlcnQuY29tL0NQUzAIBgZngQwBAgEwdQYIKwYBBQUHAQEEaTBnMCYGCCsGAQUF
BzABhhpodHRwOi8vc3RhdHVzLnJhcGlkc3NsLmNvbTA9BggrBgEFBQcwAoYxaHR0
cDovL2NhY2VydHMucmFwaWRzc2wuY29tL1JhcGlkU1NMUlNBQ0EyMDE4LmNydDAJ
BgNVHRMEAjAAMIIBAwYKKwYBBAHWeQIEAgSB9ASB8QDvAHUAu9nfvB+KcbWTlCOX
qpJ7RzhXlQqrUugakJZkNo4e0YUAAAFsb/nFXwAABAMARjBEAiAImnTSDkNO00pM
V3UayoO/5/bfY9jQ8N0fgLlkSgoE4QIgPY7RywhhLaZuM8NXKobdDRFDlKAZ7cRe
/ed1u4YQ2n8AdgCHdb/nWXz4jEOZX73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWxv
+cWnAAAEAwBHMEUCIEe+K8YCsi4v3bCePJZVmTMbYVtNLuzkCL5++1d65PHdAiEA
vALMfUfpcTOrIJFRen4QswI9AwLNrbT0syLBwa2T4hYwDQYJKoZIhvcNAQELBQAD
ggEBALtoPTrVbUmlvWqEAKq8iCXfVny6uPmQjhnkZUU6688nw7QClmvJo+69fOfo
Ub9sTylum7pKBjHzyldkk4IVbV8N6N3OMTct0yjKQomo2SQtbIKUAjBnHA963u+g
oSYneY3BPRZ5AkuMunJcABpKKDUiLuXJTj06R103Tww338o21685iC2+dJiEuGcW
xrcgNJyXBc6BiraWVyiXwMT32ic6Z+VPVVFl0SzpxNsGOtf6X3Lq8P1QrrRQwtNh
uVWqmnGRtwfGhE5qKC6G/lGvQ3lBKoaF9FqsmNlCRzXAWt/s8tzdl66pJ+N9kDe6
bRtBtlAoYM4BKMDvL4dxeXNAQvo=
-----END CERTIFICATE-----
subject=CN = *.forpsi.com

issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 2018

---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3580 bytes and written 480 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: A661A8D74A87129DC017A05162E3890C97B2EC21AD3A96E32B7A76E1D092653C
    Session-ID-ctx:
    Master-Key: 7EAC55C6753E4EA12B629D3EA80D8A9C10442CCD4712B5471652AA94EFF11B7910DB1F33D256ED5495C74CB9435EC441
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 9d e7 77 7c 0c 40 a3 0d-aa 34 b2 37 76 11 90 09   ..w|.@...4.7v...
    0010 - 87 3b 85 05 0d 48 35 c3-e0 f5 f3 fb d8 9c 24 ff   .;...H5.......$.
    0020 - 48 b0 84 bb 66 52 8d c8-66 ba f2 42 b3 02 47 ac   H...fR..f..B..G.
    0030 - 14 0a 4c be 11 55 67 a1-d0 f0 de d5 8d fe 09 4e   ..L..Ug........N
    0040 - b0 55 52 27 76 df 19 d1-37 71 a9 86 55 c3 db f3   .UR'v...7q..U...
    0050 - ac cc a7 5e e3 6d dc 0d-67 37 23 8c 23 88 98 80   ...^.m..g7#.#...
    0060 - cb a3 a5 8e c9 af a1 bb-ea 29 a8 1d 1b 38 68 e6   .........)...8h.
    0070 - ed 55 df 77 9f 0c b3 b3-e6 fe 01 b2 5b c3 3f 55   .U.w........[.?U
    0080 - 09 9d b7 4c 8d 8b 4b 4e-05 2a e1 03 3f 23 5d 75   ...L..KN.*..?#]u
    0090 - 7f 26 05 2d c5 90 96 cb-cb b5 ad a1 06 35 9d 5f   .&.-.........5._
    00a0 - ba 03 ca fe c6 ce 25 b9-cc 58 40 71 74 52 1b 22   ......%..X@qtR."

    Start Time: 1585147887
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
250 OK

quit
221 2.0.0 cmg11.fe.forpsi.com cmgsmtp closing connection
read:errno=0
 
when you see 250 OK

send the email with

Helo localhost
Mail from: support@freebsd.org
Rcpt to: santa@northpole.com
DATA
Subject: test email
From: support@freebsd.org
ENTER MESSAGE
(blank line)
.

does it send? or error part way?
Code:
helo localhost
250 cmg12.fe.forpsi.com hello [90.176.149.141], pleased to meet you
mail from: suupport@freebsd.org
250 2.1.0 <suupport@freebsd.org> sender ok
rcpt to: santa@northpole.com
550 5.1.1 H7bJjOLs8MZxxH7bdjXooo Sorry, no user here by that name
Code:
rcpt to: actualaddress
250 2.1.5 <actualaddress> recipient ok
data
354 OK
testestset
.
250 2.0.0 H7bJjOLs8MZxxH7bdjXooo mail accepted for delivery

...and yes, it does deliver a blank message to my inbox.
 
heres why your validation is failing

the server name of the mail server is not covered by their wild card cert..

cmg11.fe.forpsi.com

Certificate Information:Common Name: *.forpsi.com
Subject Alternative Names: *.forpsi.com, forpsi.com
Valid From: August 7, 2019
Valid To: October 6, 2020
Issuer: RapidSSL RSA CA 2018, DigiCert Inc Write review of DigiCert
Serial Number: 0258d566a57a5adc609f491b32ac1696

a wild card certificate for email can only contain a single sub domain ..

so abc.forpsi.com is valid
but
abc.xyz.forpsi.com is not

It not technically wrong .. but it will fail certificate validation by an mta
 
heres why your validation is failing

the server name of the mail server is not covered by their wild card cert..

cmg11.fe.forpsi.com

Certificate Information:Common Name: *.forpsi.com
Subject Alternative Names: *.forpsi.com, forpsi.com
Valid From: August 7, 2019
Valid To: October 6, 2020
Issuer: RapidSSL RSA CA 2018, DigiCert Inc Write review of DigiCert
Serial Number: 0258d566a57a5adc609f491b32ac1696

a wild card certificate for email can only contain a single sub domain ..

so abc.forpsi.com is valid
but
abc.xyz.forpsi.com is not

It not technically wrong .. but it will fail certificate validation by an mta
Thank you, but this is not the issue.

The issue is not a failing certificate or anything to do with the certificate. The issue is that the daily output is being addressed to the wrong address. The certificate has nothing to do with this.
 
if thats the case then .. and you can relay mail to and from command line .. and there no errors.. the issue is with exchange/mailbox server .. or the mua. not with transport ..
 
what do the message headers show .. the original email address you used in testing? .. or the alias

and i guess the better question is.. are you sure you need an alias vs an address re-write ... the other option would be an alias map/rewrite

there is a big difference ..

An alias map is a method for substituting an email address with another for the purpose of policy filtering, quarantine summaries, and user block lists.
Address rewriting, on the other hand, alters the address (and, optionally, the message headers) of an email message either before or after it is processed by the policy.

so if for example you are sending an email to user A .. and expecting it to be delivered to user B's in box .. you need a message rewrite or map.. this would essentially look for mail to user A .. if it finds one it will do a message split and stuff the to address with user B's email address before it is delivered down stream. .. the downstream mailbox would never know user A exists because your doing the rewrite upstream ...

if your trying to use a shared email box and see a bunch of emails from all sorts of different people .. this would be an example of an alias map.. where the mua understands user A B C and it associates the alias to mailbox D .. all mail is NOT re-written to a specific user ..

a good example of why you would want an alias map .. for example if you wanted to apply a bunch of different policy and then report upon it (ie a quarantine digest) you could alias all of that to a single email box .. none of the mail is actually modified.. the mail mta simply understands the mail alias exists and it should accept the message.
 
if thats the case then .. and you can relay mail to and from command line .. and there no errors.. the issue is with exchange/mailbox server .. or the mua. not with transport ..
Thank you. As far as I can see in the log file, sendmail attempts to deliver the daily run output message. I would
conclude from that that the program attempting the delivery is sendmail. As far as I understand, sendmail is not a MUA. The program that correctly refuses to receive the message is Forpsi's mail exchanger, and it is very right to do so because sendmail is trying to use the incorrect recipient address.

As for the /etc/aliases (/etc/mail/aliases) file, it is used, among other things, to specify a real-world address for the person who should receive root's mail. That part, at least, has absolutely nothing to do with policy filtering, quarantines or block lists.
 
As for the /etc/aliases (/etc/mail/aliases) file, it is used, among other things, to specify a real-world address for the person who should receive root's mail. That part, at least, has absolutely nothing to do with policy filtering, quarantines or block lists.
Agreed.

There is really no reason why mail sent to someuser@domain.tld gets translated to root@domain.tld. But, speaking of rewriting, did you perhaps modify sendmail's configuration using the *.mc or *.cf files?
 
I have edited sendmail's configuration directly in the cf file. I first set up a smart relay (DS) and then deleted the smart relay (left DS empty). As far as I know, I made no other changes. I am under the assumption that sendmail, by default, uses /etc/aliases (/etc/mail/aliases).
 
Agreed.

There is really no reason why mail sent to someuser@domain.tld gets translated to root@domain.tld. But, speaking of rewriting, did you perhaps modify sendmail's configuration using the *.mc or *.cf files?
As for the conversion of the recipient address:

The initial address is root@r710.domain.tld. From /etc/aliases it follows that root is to be changed to user@domain.tld. The message should go to user@domain.tld. The real-world result is that delivery is attempted to root@domain.tld, and the decision to attempt that address is made by sendmail, not by the receiving mail exchanger.
 
/etc/aliases is for inbound mail .. not outbound

if your generating an email and sending it outbound .. you will need an alias map and transport rules to rewrite mail from root@mydomain to user@external domain .. then a rule that says mail to external domain should be sent externally

either that or have whatever task your generating the email from send the mail directly to user@external domain and then a transport rule to send it externally like any other external message. This is the best way so you can do things like hash dkim or other security features ..
 
The initial address is root@r710.domain.tld.
That's the source (From:) address, yes. But that's mostly irrelevant.

I have edited sendmail's configuration directly in the cf file. I first set up a smart relay (DS) and then deleted the smart relay (left DS empty).
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.

As far as I know, I made no other changes. I am under the assumption that sendmail, by default, uses /etc/aliases (/etc/mail/aliases).
It does. But rewriting source or destination domains (or users) could potentially cause weird loops, which might be the case here.
 
Back
Top