Sendmail Smarthost

[denverh]

Hello,

At home I have a number of FreeBSD systems (14.2) and I have all of them sending the periodic cron mail reports to my main desktop system using aliases. The main system is using sendmail, all the others the default dma. I've been using Thunderbird for a long time and had it configured to read the file in /var/mail where everything went. That stopped working some time ago, so I've been running mutt in a terminal beside the Thunderbird window ever since. That works, of course, but it's kind of clunky. I had some time the other day and thought I would see if I could get sendmail to forward everything to my regular email account so I could dispense with mutt.

I first tried with dma and that was pretty easy. I could do it that way on all the systems, but they're already forwarding everything to the main system anyway, it would require a lot of duplicated effort, and the main system is already running sendmail. The settings I need (from Thunderbird) are port 465, normal password, and SSL/TLS. I've been wading through reams and reams of documentation on sendmail, and I still haven't gotten it to work. This seems like it should be fairly simple and it's not a complicated system. But so far I haven't been successful. The configuration I have right now is trying to use STARTTLS which isn't going to work in this case.

I've been using FreeBSD for a long time, mostly as a desktop system, so setting up mail this way is new territory, and some of the terminology is unfamiliar. What are the changes I would need to make to a vanilla system to get this to work? I've already rebuilt sendmail with SASL support and installed cyrus-sasl and cyrus-sasl-saslauthd. But other than that, assume a fresh system.

Regards,

Denver

 

[Jim L.]

You include basically zero information about your existing sendmail setup, but as a starting point, if your sendmail machine is receiving mails as "example.com" and therefore all your systems all currently forwarding their "root" mail to denverh@example.com as an example;

AND, if "denverh@example.com" on your sendmail machine is your exact user name (i.e., you log in to the sendmail machine as "denverh"), then on your sendmail machine, try editing /etc/mail/aliases:

# vi /etc/mail/aliases

Perhaps towards the bottom of the file, edit in:

denverh: my_other_email@myrealemail.com

Ensure there is no other entry for "denverh" (i.e., search the file for ^denverh). If there is, comment out the old one.

Save the file, and then run:

# make -C /etc/mail
# make -C /etc/mail restart

Beware that depending on their spam policies, the mail server at "myrealemail.com" might not accept your forwarded emails, in which case they'll probably bounce back to you or to "postmaster@example.com".

OTOH, if the above is not what you're doing, then you'll need to include more detail about your sendmail/mutt setup to increase the chances for progress and minimize the chances of email loops.

 

[denverh]

You include basically zero information about your existing sendmail setup, but as a starting point, if your sendmail machine is receiving mails as "example.com" and therefore all your systems all currently forwarding their "root" mail to denverh@example.com as an example;

AND, if "denverh@example.com" on your sendmail machine is your exact user name (i.e., you log in to the sendmail machine as "denverh"), then on your sendmail machine, try editing /etc/mail/aliases:

# vi /etc/mail/aliases

Perhaps towards the bottom of the file, edit in:

denverh: my_other_email@myrealemail.com

Ensure there is no other entry for "denverh" (i.e., search the file for ^denverh). If there is, comment out the old one.

Save the file, and then run:

# make -C /etc/mail
# make -C /etc/mail restart

Beware that depending on their spam policies, the mail server at "myrealemail.com" might not accept your forwarded emails, in which case they'll probably bounce back to you or to "postmaster@example.com".

OTOH, if the above is not what you're doing, then you'll need to include more detail about your sendmail/mutt setup to increase the chances for progress and minimize the chances of email loops.

Thanks for the response, and sorry about the lack of detail, I wasn't sure what to include. As an example, I have one system, bsdnas, which forwards root's email to the main system, dhbsd, using /etc/aliases:

root: root@dhbsd

Then, dhbsd should be able to send everything to my personal email with the /etc/aliases:

root: denver@something.com

Sendmail on dhbsd is completely back to default settings, except that it's been compiled with SASL support. I'm trying to have the dhbsd system send root's mail from all my systems to my personal email: denver@someting.com. I'm not trying to use something.com to forward emails somewhere else.
My .muttrc:

set pager_index_lines=6
set mail_check=10
set timeout=20

And the environment variable MAIL = /var/mail/dhull

When I configure dma to send mail to my personal account, it looks like this:

SMARTHOST mail.something.com
PORT 465
AUTHPATH /etc/dma/auth.conf
SECURETRANSFER
MASQUERADE root@dhbsd

(I'm not completely sure that the MASQUERADE setting is correct, but it seems to work for locally generated mail)

The auth file for dma:

denver@something.com|mail.something.com:password

Thanks,

Denver

 

[VladiBG]

MASQUERADE root@dhbsd

Is dhbsd valid/registered domain?

Here's my notes about sendmail and dma

 

[hruodr]

See here:

H

Thread 'mail, metamail, gpg, openssl, sendmail, fetchmail, etc AS MAIL CLIENT'

Mar 11, 2021

This thread is dedicated to simple command line tools as mail client for normal desktop users, in order
to show that FreeBSD has a past and a future as desktop system.

My contribution is to configure sendmail as smart host, in order that one can use normal mail to send mails. Perhaps someone can follow with fetchmail?

I will configure sendmail with gmail, but better you use other provider. I am not an expert, hence, corrections and
improvements are welcome. I hope, I will not offend those that want to mutilate FreeBSD MTA support to their needs.
I just want to...

• hruodr
• Replies: 8
• Forum: Web and Network Services

• 

 

[denverh]

Is dhbsd valid/registered domain?

No, it's the name of my desktop system.

Here's my notes about sendmail and dma

Yes, I remember unsuccessfully trying that earlier.

Thanks.

 

[denverh]

See here:

H

Thread 'mail, metamail, gpg, openssl, sendmail, fetchmail, etc AS MAIL CLIENT'

Mar 11, 2021

This thread is dedicated to simple command line tools as mail client for normal desktop users, in order
to show that FreeBSD has a past and a future as desktop system.

My contribution is to configure sendmail as smart host, in order that one can use normal mail to send mails. Perhaps someone can follow with fetchmail?

I will configure sendmail with gmail, but better you use other provider. I am not an expert, hence, corrections and
improvements are welcome. I hope, I will not offend those that want to mutilate FreeBSD MTA support to their needs.
I just want to...

• hruodr
• Replies: 8
• Forum: Web and Network Services

• 

Nice clear instructions. When I follow them the connection to mail.something.com times out. Here's the output from a mail -v command:

mail -v -s qwerty denver@something.com
lvg
EOT
denver@something.com... Connecting to [127.0.0.1] via relay...
220 dhbsd.lan ESMTP Sendmail 8.18.1/8.18.1; Mon, 24 Feb 2025 17:00:46 -0600 (CST)
>>> EHLO dhbsd.lan
250-dhbsd.lan Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> VERB
250 2.0.0 Verbose mode
>>> MAIL From:<dhull@dhbsd.lan> SIZE=56
250 2.1.0 <dhull@dhbsd.lan>... Sender ok
>>> RCPT To:<denver@something.com>
>>> DATA
250 2.1.5 <denver@something.com>... Recipient ok
354 End data with <CR><LF>.<CR><LF>
>>> .
050 <denver@something.com>... Connecting to something.com. port 465 via relay...
050 <denver@something.com>... Deferred: Connection reset by something.com.
250 2.0.0 51ON0kM5056712 Message accepted for delivery
denver@something.com... Sent (51ON0kM5056712 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 dhbsd.lan closing connection

Maillog from one of the retries:

Feb 24 17:09:56 dhbsd sendmail[57629]: 51ON0kM5056712:
to=<denver@something.com>, ctladdr=<dhull@dhbsd.lan> (1022/1022),
delay=00:09:10, xdelay=00:02:45, mailer=relay, pri=210367,
relay=something.com. [111.111.111.111], dsn=4.4.2, stat=Deferred: Connection reset by something.com.

I also tried port 587, which doesn't time out but results in the message "SMTP AUTH is required for message submission on port 587". In the past, I've never been able to get 587 to work at all, just 465 with SSL/TLS. And I'm pretty sure the original instructions I got from the hosting service said to set things up that way.

I'm also curious about the certificate that I had to create. I didn't need to do that for dma, so why is it necessary for this?

Thanks,

Denver

 

[denverh]

OK, I've made some progress. I can successfully send email from my main system to my regular email account. I had neglected to create a user with the correct name/password for my email account.

The problem now is that mail from other systems on my local network, and mail from jails on the main system, all get dumped into /var/mail instead of sent to my regular email account. I've put this in /etc/mail/access:

Connect:localhost        RELAY
Connect:127.0.0.1        RELAY
Connect:192.168.0        RELAY

My sendmail mc file looks like this now:

VERSIONID(`2021-03-11 sendmail as client on FreeBSD 11.4')
OSTYPE(freebsd6)
FEATURE(access_db, `hash -o /etc/mail/access.db')
define(`SMART_HOST',`mail.something.com')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 465')dnl
define(`ESMTP_MAILER_ARGS', `TCP $h 465')dnl
define(`confAUTH_OPTIONS', `A p')dnl
TRUST_AUTH_MECH(`EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
FEATURE(`authinfo',`hash -o /etc/mail/auth/client.db')dnl
MASQUERADE_DOMAIN(`dhbsd.lan')dnl
MASQUERADE_AS(`something.com')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`masquerade_entire_domain')dnl

According to what I've been reading, the access file is what should be telling sendmail how to deal with incoming mail, and what I have should do what I want, but it doesn't. Everything sent to root@dhbsd from other systems just ends up in /var/mail/root on dhbsd. Any suggestions?

Thanks,

Denver

 

[Jim L.]

Everything sent to root@dhbsd from other systems just ends up in /var/mail/root on dhbsd.

Check that your /etc/mail/aliases on dhbsd contains a line beginning with root: and pointing to where you want the mail to be forwarded, and re-do a make just for good measure:

# cd /etc/mail
# grep ^root: aliases
root:    account@my_regular_email.com
# make ; make install ; make restart

If all that is still good, post the excerpt from your /var/log/maillog that shows dhbsd receiving and processing an e-mail for root.

Also, I often like to have define(`confLOG_LEVEL', `15') in my .mc to get more logging detail. ymmv

 

[denverh]

Check that your /etc/mail/aliases on dhbsd contains a line beginning with root: and pointing to where you want the mail to be forwarded, and re-do a make just for good measure:

# cd /etc/mail
# grep ^root: aliases
root:    account@my_regular_email.com
# make ; make install ; make restart

Yes, the dhbsd alias is correct. Mail generated by dhbsd is going to the right place, it's just mail from other hosts on the same network that ends up in dhbsd:/va
If all that is still good, post the excerpt from your /var/log/maillog that shows dhbsd receiving and processing an e-mail for root.

Also, I often like to have define(`confLOG_LEVEL', `15') in my .mc to get more logging detail. ymmv

Yes, dhbsd:/etc/aliases is correct, mail generated by dhbsd is going to the right place. Mail generated by other hosts on the same network alaised to root@dhbsd.lan end up in dhbsd:/var/mail/root. Thanks for the tip on setting loglevel in the mc file. I hadn't been able to find that. Here's the result of "mail -vs zxcvb root@dhbsd.lan" sent from a jail running on dhbsd, by user dhull after "su - root":

Feb 26 14:35:10 dhbsd sm-mta[66821]: NOQUEUE: connect from fbsd11 [192.168.0.38]
Feb 26 14:35:10 dhbsd sm-mta[66821]: AUTH: available mech=SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 SCRAM-SHA-224 SCRAM-SHA-1 DIGEST-MD5 OTP NTLM CRAM-MD5 ANONYMOUS, allowed mech=EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: Milter: no active filter
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 220 dhbsd.lan ESMTP Sendmail 8.18.1/8.18.1; Wed, 26 Feb 2025 14:35:10 -0600 (CST)
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: <-- EHLO fbsd11.lan
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-dhbsd.lan Hello fbsd11 [192.168.0.38], pleased to meet you
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-ENHANCEDSTATUSCODES
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-PIPELINING
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-EXPN
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-VERB
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-8BITMIME
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-SIZE
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-DSN
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-ETRN
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-AUTH DIGEST-MD5 CRAM-MD5
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250-DELIVERBY
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250 HELP
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: <-- VERB
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250 2.0.0 Verbose mode
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: <-- MAIL From:<dhull@fbsd11.lan> SIZE=52 AUTH=dhull@fbsd11.lan
Feb 26 14:35:10 dhbsd sm-mta[66821]: ruleset=trust_auth, arg1=dhull@fbsd11.lan, relay=fbsd11 [192.168.0.38], reject=550 5.7.1 <dhull@fbsd11.lan>... not authenticated
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250 2.1.0 <dhull@fbsd11.lan>... Sender ok
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: <-- RCPT To:<root@dhbsd.lan>
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 050 <root@dhbsd.lan>... aliased to root@dhbsd
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: alias <root@dhbsd.lan> => root@dhbsd
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250 2.1.5 <root@dhbsd.lan>... Recipient ok
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: <-- DATA
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 354 End data with <CR><LF>.<CR><LF>
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: from=<dhull@fbsd11.lan>, size=350, class=0, nrcpts=1, msgid=<202502262035.51QKZA6v066820@fbsd11.lan>, proto=ESMTP, daemon=IPv4, relay=fbsd11 [192.168.0.38]
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 050 <root@dhbsd.lan>... Connecting to local...
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 050 <root@dhbsd.lan>... Sent
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: to=<root@dhbsd.lan>, ctladdr=<dhull@fbsd11.lan> (1022/1022), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30350, dsn=2.0.0, stat=Sent
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: done; delay=00:00:00, ntries=1
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYP066821: --- 250 2.0.0 51QKZAYP066821 Message accepted for delivery
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYQ066821: <-- QUIT
Feb 26 14:35:10 dhbsd sm-mta[66821]: 51QKZAYQ066821: --- 221 2.0.0 dhbsd.lan closing connection

 

[Jim L.]

Given that your authentication is failing, why not shut authentication off in sendmail, at least until you get the forwarding to work? Then once the forwarding is working, you can turn authentication back on. That way we're not stubbing our toe on more than one problem at a time.

And just for review, can you please post the output of:

# cd /etc/mail
# hostname
# ls -ltr | tail
# cat aliases
# sendmail -bt
> $=w
(Ctrl-D to exit)
# sendmail -bv root
# sendmail -bv root@dhbsd.lan

Thanks!

 

[denverh]

Given that your authentication is failing, why not shut authentication off in sendmail, at least until you get the forwarding to work? Then once the forwarding is working, you can turn authentication back on. That way we're not stubbing our toe on more than one problem at a time.

And just for review, can you please post the output of:

# cd /etc/mail
# hostname
[/QUOTE]
dhbsd.lan
[QUOTE="Jim L., post: 691694, member: 79645"]

# ls -ltr | tail
[/QUOTE]
[CODE]-rw-r--r--  1 root wheel   43B Feb 25 16:38 local-host-names
-rw-r--r--  1 root wheel  1.2K Feb 25 17:26 notes.txt
-rw-r--r--  1 root wheel  203B Feb 25 18:57 mailertable
-rw-r-----  1 root wheel  128K Feb 25 18:58 mailertable.db
-rw-r--r--  1 root wheel  689B Feb 26 14:24 access
-rw-r-----  1 root wheel  128K Feb 26 14:34 access.db
-r--r--r--  1 root wheel   53K Feb 26 14:34 sendmail.cf
-r--r--r--  1 root wheel   41K Feb 26 14:34 submit.cf
-rw-r--r--  1 root wheel  961B Feb 26 17:00 dhbsd.lan.mc
-rw-r--r--  1 root wheel   53K Feb 26 17:00 dhbsd.lan.cf

# cat aliases

root:    denver@something.com

# Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
postmaster: root

# General redirections for pseudo accounts
_dhcp:    root
_pflogd: root
auditdistd:    root
bin:    root
bind:    root
daemon:    root
games:    root
hast:    root
kmem:    root
mailnull: postmaster
man:    root
news:    root
nobody:    root
operator: root
pop:    root
proxy:    root
smmsp:    postmaster
sshd:    root
system:    root
toor:    root
tty:    root
usenet: news
uucp:    root

# Well-known aliases -- these should be filled in!
# manager:
# dumper:

# BUSINESS-RELATED MAILBOX NAMES
# info:
# marketing:
# sales:
# support:

# NETWORK OPERATIONS MAILBOX NAMES
abuse:    root
# noc:        root
security:    root

# SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES
ftp:         root
ftp-bugs:     ftp
# hostmaster:     root
# webmaster:     root
# www:         webmaster

# NOTE: /var/msgs and /var/msgs/bounds must be owned by sendmail's
#    DefaultUser (defaults to mailnull) for the msgs alias to work.
#
# msgs: "| /usr/bin/msgs -s"

# bit-bucket: /dev/null
# dev-null: bit-bucket

# sendmail -bt
> $=w

sendmail: no recipients

However, sendmail -bt root, followed with $=w reports this:

sendmail -bt root
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> $=w
[fbsd09.lan]
devuan.lan
devuan
[192.168.0.49]
[192.168.0.38]
[192.168.0.53]
[192.168.0.45]
[192.168.0.57]
[192.168.0.30]
[192.168.0.54]
[IPv6:fe80:0:0:0:0:0:0:1]
fbsd09
fbsd12
fbsd13
fbsd10
fbsd11
[IPv6:0:0:0:0:0:0:0:1]
fbsd09.lan
fbsd10.lan
fbsd11.lan
fbsd12.lan
fbsd13.lan
[fbsd10.lan]
[devuan.lan]
localhost
dhbsd.lan
dhbsd
[127.0.0.1]
[devuan]
[fbsd12.lan]
[fbsd13.lan]
[fbsd09]
[fbsd13]
[fbsd11]
[fbsd12]
[fbsd10]
[fbsd11.lan]

(Ctrl-D to exit)
# sendmail -bv root

This just waits for input. ^D quietly exits.

# sendmail -bv root@dhbsd.lan[/code]

Same with this one.

Thanks!

I commented out, with ^dnl, four lines that included some form of "AUTH": two define's, a FEATURE, and a TRUST_AUTH_MECH.

Thanks,

Denver

 

[Jim L.]

There's likely more, but for starters, you need to:

# cd /etc/mail
# make; make install; make restart

In your output above, notice that dhbsd.lan.cf is newer than sendmail.cf. That means you haven't done a make install recently.

Always remember that at startup (or restart), sendmail uses the sendmail.cf file. So when you modify dhbsd.lan.mc and do make, you get a new dhbsd.lan.cf file, but sendmail doesn't use that, so you haven't changed anything yet. You need to do a make install to copy dhbsd.lan.cf to sendmail.cf and dhbsd.lan.submit.cf to submit.cf, and then make restart to tell sendmail to shutdown, re-read the new sendmail.cf, and restart.

Also, ensure that your /etc/mail/mailer.conf is correct. diff-ing it against /usr/share/examples/sendmail/mailer.conf should show no differences:

# diff /etc/mail/mailer.conf /usr/share/examples/sendmail/mailer.conf
#

If there are differences (other than comments), set your mailer.conf aside and copy in the known good one from the examples:

# mv -vi mailer.conf mailer.conf.old
# cp -vp /usr/share/examples/sendmail/mailer.conf .

The restart sendmail one more time and try again:

# make; make install; make restart
# sendmail -bt <<< '$=w'
# sendmail -bv root
# sendmail -bv root@dhbsd.lan

 

[denverh]

There's likely more, but for starters, you need to:

# cd /etc/mail
# make; make install; make restart

In your output above, notice that dhbsd.lan.cf is newer than sendmail.cf. That means you haven't done a make install recently.

Always remember that at startup (or restart), sendmail uses the sendmail.cf file. So when you modify dhbsd.lan.mc and do make, you get a new dhbsd.lan.cf file, but sendmail doesn't use that, so you haven't changed anything yet. You need to do a make install to copy dhbsd.lan.cf to sendmail.cf and dhbsd.lan.submit.cf to submit.cf, and then make restart to tell sendmail to shutdown, re-read the new sendmail.cf, and restart.

Also, ensure that your /etc/mail/mailer.conf is correct. diff-ing it against /usr/share/examples/sendmail/mailer.conf should show no differences:

# diff /etc/mail/mailer.conf /usr/share/examples/sendmail/mailer.conf
#

If there are differences (other than comments), set your mailer.conf aside and copy in the known good one from the examples:

# mv -vi mailer.conf mailer.conf.old
# cp -vp /usr/share/examples/sendmail/mailer.conf .

The restart sendmail one more time and try again:

I know the sendmail.cf was older, but I don't think there was any difference in the mc file - I had saved it without actually making any changes. Anyway, the mailer.conf file was still from earlier attempts and experiments. I thought I had copied it back from /usr/share/examples/sendmail/mailer.conf, but apparently not. Here are the new results:

# make; make install; make restart
# sendmail -bt <<< '$=w'
[/QUOTE]
[CODE]
sendmail -bt <<< '$=w'
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> [fbsd09.lan]
devuan.lan
devuan
[192.168.0.49]
[192.168.0.38]
[192.168.0.53]
[192.168.0.45]
[192.168.0.57]
[192.168.0.30]
[192.168.0.54]
[IPv6:fe80:0:0:0:0:0:0:1]
fbsd09
fbsd12
fbsd13
fbsd10
fbsd11
[IPv6:0:0:0:0:0:0:0:1]
fbsd09.lan
fbsd10.lan
fbsd11.lan
fbsd12.lan
fbsd13.lan
[fbsd10.lan]
[devuan.lan]
localhost
dhbsd.lan
dhbsd
[127.0.0.1]
[devuan]
[fbsd12.lan]
[fbsd13.lan]
[fbsd09]
[fbsd13]
[fbsd11]
[fbsd12]
[fbsd10]
[fbsd11.lan]
>

# sendmail -bv root

sendmail -bv root
root... deliverable: mailer local, user root

# sendmail -bv root@dhbsd.lan[/code]

sendmail -bv root@dhbsd.lan
root@dhbsd.lan... deliverable: mailer local, user root

This is all with AUTH disabled in sendmail.cf.

Thanks,

Denver

 

[Jim L.]

Optionally, you may want to add to /etc/mail/dhbsd.lan.mc:

define(`confDONT_PROBE_INTERFACES', `true')

and then do make; make install; make restart

That should clean up a lot of the extraneous domains in the '$=w' output.

More later....

 

[denverh]

Optionally, you may want to add to /etc/mail/dhbsd.lan.mc:

define(`confDONT_PROBE_INTERFACES', `true')

and then do make; make install; make restart

Thanks, I added that. I was wondering: what's the difference between "make; make install; make restart" and "make cf install restart"?

 

[Jim L.]

what's the difference between "make; make install; make restart" and "make cf install restart"?

make (or make all) is more comprehensive than make cf. make; make install; make restart is the same as make all install restart if you like.

I notice you don't have any MAILER() lines in your /etc/mail/dhbsd.lan.mc:

MAILER(local)
MAILER(smtp)

In general, you may want to set aside your (non-working) /etc/mail/dhbsd.lan.mc and revert to the stock .mc, at least until you get the basics working. Then you can add back the other features, one at a time, and test each one to make sure nothing breaks after re-enabling your desired features.

# cd /etc/mail
# mv -vi /etc/mail/dhbsd.lan.mc /etc/mail/dhbsd.lan.mc.safety
# mv -vi /etc/mail/dhbsd.lan.submit.mc /etc/mail/dhbsd.lan.submit.mc.safety
# rm *.cf
# make

That will give you a /etc/mail/dhbsd.lan.mc that is exactly the same as the stock /etc/mail/freebsd.mc. Now you can edit your new, simplified dhbsd.lan.mc and add back the:

define(`confLOG_LEVEL', `15')
define(`confDONT_PROBE_INTERFACES', `true')

and then:

# make all install restart
# sendmail -bt <<< '$=w'
# sendmail -bv root
# sendmail -bv root@dhbsd.lan

What's that output look like?

 

[denverh]

make (or make all) is more comprehensive than make cf. make; make install; make restart is the same as make all install restart if you like.

Thanks, that's what I thought but wasn't sure.

I notice you don't have any MAILER() lines in your /etc/mail/dhbsd.lan.mc:

MAILER(local)
MAILER(smtp)

In general, you may want to set aside your (non-working) /etc/mail/dhbsd.lan.mc and revert to the stock .mc, at least until you get the basics working. Then you can add back the other features, one at a time, and test each one to make sure nothing breaks after re-enabling your desired features.

# cd /etc/mail
# mv -vi /etc/mail/dhbsd.lan.mc /etc/mail/dhbsd.lan.mc.safety
# mv -vi /etc/mail/dhbsd.lan.submit.mc /etc/mail/dhbsd.lan.submit.mc.safety
# rm *.cf
# make

That will give you a /etc/mail/dhbsd.lan.mc that is exactly the same as the stock /etc/mail/freebsd.mc. Now you can edit your new, simplified dhbsd.lan.mc and add back the:

define(`confLOG_LEVEL', `15')
define(`confDONT_PROBE_INTERFACES', `true')

OK, that's all done.

and then:

# make all install restart
# sendmail -bt <<< '$=w'
[/QUOTE]
[CODE]ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> [IPv6:0:0:0:0:0:0:0:1]
fbsd11.lan
localhost
dhbsd.lan
dhbsd
bsdnas.lan
>

# sendmail -bv root

sendmail -bv root
denver@something.com... deliverable: mailer esmtp, host something.com., user denver@something.com

# sendmail -bv root@dhbsd.lan[/code]

sendmail -bv root@dhbsd.lan
denver@something.com... deliverable: mailer esmtp, host something.com., user denver@something.com

What's that output look like?

 

[Jim L.]

¡Muy bien! So now sendmail understands where to forward the email. Now, before sending mail out into the real world, I'd suggest you temporarily change /etc/mail/aliases to just forward to denver@dhbsd.lan or whatever your unprivileged user account is on your machine. Then you can try sending to root@dhbsd.lan from your jails, and the emails should land in /var/mail/denver on dhbsd.lan.

For that matter, you can confirm what sendmail will do with denver@dhbsd.lan:

# sendmail -bv denver@dhbsd.lan

Hopefully:

denver@dhbsd.lan... deliverable: mailer local, user denver

THEN you can test away, emailing from your jails to root@dhbsd.lan, and you can adjust your masquerading, and inspect the results by looking at the messages in /var/mail/denver.

 

[denverh]

Thanks for all the help everyone, but it seems like I've gone full circle now, and connections to the external MTA always time out. Even with the configuration that was working before. I've spent too much time on this for now, so I'm going to give it a rest for a while. I'm not sure now that what I did earlier that seemed to get the connection to mail.something.com working actually had anything to do with it. It seems to me that the entry in /usr/local/lib/sasl2/Sendmail.conf that says to use the local passwd file would be for incoming authentications, while the sendmail FEATURE('authinfo', ...) would be for outgoing. If that's correct, then I have no idea why it started working the other day, and even less about why it doesn't now. Anyway, I'll try again later when I have more time.

Thanks again for all the help,

Denver

 

[Jim L.]

Simplify. Don't try to get everything working at once. Get the relaying working first. Once that works, add the domain masquerading. Once THAT works, add the authentication back in. And make backups or your sendmail configs in between phases, so you've got a known-good relaying setup that doesn't yet do masquerading, etc.

 

[denverh]

Simplify. Don't try to get everything working at once. Get the relaying working first. Once that works, add the domain masquerading. Once THAT works, add the authentication back in. And make backups or your sendmail configs in between phases, so you've got a known-good relaying setup that doesn't yet do masquerading, etc.

Yes, good advice. One step at a time.

Thanks,

Denver