[Triple_Nothing]

I might just be off on these things due to my recent brain surgery, because my intent seems simple. I have Postfix setup and running perfectly fine using their How-To listed first below. The only thing I need to allow is the users to send mail. The basic catch is due to this being a dedicated server and no user is local. Local sends work fine, but with the users being randomly around the world, I just need to allow them to send.

Of all the onlines I have seem to come across, it either seems to be relays or SASL, which I must be overlooking something. As a temp start, I'm willing to take a quick note that will "allow all" to permit such until it is set up as truly intended to verify the user, which is the true goal.

Successful setup for incoming, and internal/local send: https://help.ubuntu.com/community/Po...asicSetupHowto

[requinix]

edit: Wait a second. How are your local sends working if you don't have users? And for incoming emails, how did you set up the accounts?

[Triple_Nothing]

Well, we can view this as an initial setup with nothing more than that page I linked. The local users/accounts are defined via user via local name, and e-mail is pretty much currently account@domain.com. The account can be added remotely to any preferred client to receive and read their e-mails. If I use PuTTY for my remote access to do my setup/config, I can access it internally via telnet and successfully send an e-mail to a local account, or a remote address as well. When I attempt to do the same thing via telnet externally, I can send an e-mail towards a local account (inbound), but cannot attempt to send externally.

So, generally speaking, in reference to sending an e-mail TO an external address, I can successfully send to external addresses if sending it from the local system, but NOT from a remote system using a local FROM address.

[requinix]

Okay, so

1. I think you don't have users set up the way you want? You have it with the regular system accounts thing but presumably don't want to have to do that for everyone. Because it's not like these people will be SSHing in. You could still do it, of course, as it's not necessarily bad as long as you're blocking SSH logins too - that is, both at the firewall level and in /etc/passwd.

2. Sending using a valid user and the right domain,
(a) from a local connection to a local account works
(b) from a remote connection to a local account works
(c) from a local connection to a remote address works
(d) from a remote connection to a remove address does not work

The first two should be working since that's how a mail server needs to work in the first place.
The second two boil down to whether the server trusts the client enough to send emails to places it does not control. That is, every other server on the internet. And external clients aren't trusted.

The answer to both problems could be SASL. What are you doing for IMAP access?

[Triple_Nothing]

(c) from a local connection to a remote address works works just fine. No restrictions via any local actions.

Due to my work hours, I haven't jumped into too much this week. I have set up and tested IMAP only to the lower portion of the following link. I have not done any alias or forwarding. I've only done basic testing with POP3/IMAP and they both currently function the same.

Current reference: https://help.ubuntu.com/community/Po...asicSetupHowto

Edit: I did find the following that may point me in the right direction, but it appears one of their walk-throughs references Courier while the other references Dovecot. Any preference/suggestions?
https://help.ubuntu.com/community/Po...xClamSmtpHowto

[requinix]

Postfix has almost built-in support for SASL via Dovecot. If you don't have a preference either way, Dovecot will help you out more.

[Triple_Nothing]

I've swapped all back to Dovecot as I'm used to, but I also noticed during setup, settings are preset and already enabled as below. The first options is the default via the initial setup. The second shows I'd tried my own certification files, as well as the newer enable/disable option. Overall, it seems simply as-if a firewall is simply on, for this one case, but I have all firewalls currently disabled during setup, and this has never been an issue before.

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes

smtpd_tls_cert_file=/etc/ssl/certs/cert.pem
smtpd_tls_key_file=/etc/ssl/private/key.pem
smtpd_security_level=may

Edit: If I have SMTP Authentication disabled for the outgoing, the server itself returns:

Your message did not reach some or all of the intended recipients.

Subject: Another test
Sent: 7/29/2018 8:56 AM

The following recipient(s) cannot be reached:

'******@gmail.com' on 7/29/2018 8:56 AM
454 4.7.1 <******@gmail.com>: Relay access denied

However, if I have SMTP Authentication enable, the error is presented by the client's software that it fails its attempt to send.

[requinix]

A firewall would prevent you from connecting at all. Is that the problem? You can't connect? Or that you can connect but something doesn't work?

About relay access, you want SMTP authentication. That's how the server knows that it can trust the person connecting and so it is okay to send emails outside its network. So the error is to be expected.
The problem is the inability to send. What error? And what do Postfix's logs show?

[Triple_Nothing]

I would rule out firewall since I have been getting server responses throughout this.

Generally, it's simply declines. If trying without authentication, I would get the expected error. With authentication error, it sounds invalid user/pass. That's why I tried a new cert/key file. Of the 2 links, the upper is my current reference to accomplish this. The lower is my main.cf file. The smtpd_ rows commented out are my current attempts. If all are uncommented (and commenting their matching), Send/Receive just seems to hang. No success or error.

Postfix SASL Howto

http://projects.hellzoneinc.com/devs...ail-980898.txt

I've also referenced this link to check my TLS options:
Postfix TLS Support


Edit: I've gotten it to "flow", so I am getting errors to reference now. First, the 'auth' folder just didn't exists. Now it does, but the error log makes the statement:
warning: SASL: Connect to private/auth failed: Permission denied
fatal: no SASL authentication mechanisms

So, first the folder didn't exists, n now that it does, it says permission denied.

[requinix]

auth isn't a folder: it's a pipe created by Dovecot. Postfix will connect to it and the two will communicate with each other.

So if you created auth yourself, delete it. Then check your Dovecot configuration to make sure it's creating that pipe.

Postfix SASL Howto

[Triple_Nothing]

I thought that at first, but figure I was wrong. Prior to me creating the folder, the error was:
warning: SASL: Connect to private/auth failed: No such file or directory
fatal: no SASL authentication mechanisms

Edit: My reference/reasoning that I assumed I was to create a folder. Referring to the comment "Then check if … got created"
https://www.howtoforge.com/postfix-d...e-or-directory

[requinix]

"No such file" means Dovecot wasn't running or wasn't configured to create it.

That Howto has sample configuration for Dovecot. It should just be a matter of incorporating it into your own configuration and restarting Dovecot. Then you would then go to that private/ and make sure that it created the auth pipe correctly.

[Triple_Nothing]

Well, service status defines it as running. The /etc/dovecot/conf.d/10-master.conf file is the reference it is using in the error to define the "No such file". I even altered it just to see if the error altered to match to see if it is referencing this, and it does.

The following was what I added/adjusted:

1 conf.d/10-master.conf:
2 service auth {
3 ...
4 unix_listener /var/spool/postfix/private/auth {
5 mode = 0660
6 # Assuming the default Postfix user and group
7 user = postfix
8 group = postfix
9 }
10 ...
11 }
12
13 conf.d/10-auth.conf
14 auth_mechanisms = plain logi

Edit1: I just noticed they reference different, but figure it's just a version/setup reference.
Postfix SASL Howto vs https://www.howtoforge.com/postfix-d...e-or-directory
service auth { vs client {
unix_listener … { vs path =
I'm using the first/left version via the postfix.org example

Edit2: When I run ls /var/spool/postfix/private, no 'auth'-related names get listed. Suggested check from https://htyp.org/Connect_to_private/dovecot-auth_failed At least with this, we're pointed towards a single issue, currently. Just gotta figure out why 'auth' doesn't exist. ^_^

Edit3: Sorry for the edits... I confirmed the reference of the auth file back and forth, and I guess Postfix is referencing it as defined in its config, but the adjustment I did in the 10-master.conf is the one failing. Are the files in Dovecot's conf.d folder to all simply run as is? Or would I need to add this file itself somewhere to run it? dovecot.conf in this version has no include/reference to other files



Just shoot me n some How-To's… So many have you back up the original n start fresh. The single line missing that includes all that's needed was simply: !include conf.d/*.conf :-/

[requinix]

What version of Dovecot are you running, and what's the contents of whatever conf.d/*.conf file you picked for the SASL stuff?

[Triple_Nothing]

Meh. The embarrassing note is the original dovecot.conf file had the !include conf.d/*.conf at its end, but a how-to said to rename the file as a backup n start fresh, so I did everything correct from the beginning, yet sadly the single little include line that USED to be there was the hugest issue. Without one single/simple line, nothing else even exists... The simplest of things sometimes mean the most.