July 27th, 2018, 11:17 AM
-
Need to allow users to remotely SEND e-mail
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
Last edited by Triple_Nothing; July 27th, 2018 at 11:28 AM.
He who knows not that he knows not is a fool, ignore him. He who knows that he knows not is ignorant, teach him. He who knows not that he knows is asleep, awaken him. He who knows that he knows is a leader, follow him.
July 27th, 2018, 12:26 PM
-
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?
Last edited by requinix; July 27th, 2018 at 12:28 PM.
July 27th, 2018, 12:50 PM
-
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.
Last edited by Triple_Nothing; July 27th, 2018 at 12:52 PM.
He who knows not that he knows not is a fool, ignore him. He who knows that he knows not is ignorant, teach him. He who knows not that he knows is asleep, awaken him. He who knows that he knows is a leader, follow him.
July 27th, 2018, 04:55 PM
-
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?
Last edited by requinix; July 27th, 2018 at 04:58 PM.
July 27th, 2018, 09:11 PM
-
(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
Last edited by Triple_Nothing; July 27th, 2018 at 09:14 PM.
He who knows not that he knows not is a fool, ignore him. He who knows that he knows not is ignorant, teach him. He who knows not that he knows is asleep, awaken him. He who knows that he knows is a leader, follow him.
July 27th, 2018, 10:10 PM
-
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.
July 29th, 2018, 09:58 AM
-
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.
Last edited by Triple_Nothing; July 29th, 2018 at 02:17 PM.
He who knows not that he knows not is a fool, ignore him. He who knows that he knows not is ignorant, teach him. He who knows not that he knows is asleep, awaken him. He who knows that he knows is a leader, follow him.
July 29th, 2018, 02:56 PM
-
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?
July 29th, 2018, 03:32 PM
-
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.
Last edited by Triple_Nothing; July 29th, 2018 at 04:04 PM.
He who knows not that he knows not is a fool, ignore him. He who knows that he knows not is ignorant, teach him. He who knows not that he knows is asleep, awaken him. He who knows that he knows is a leader, follow him.
July 29th, 2018, 04:15 PM
-
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
July 29th, 2018, 04:30 PM
-
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
Last edited by Triple_Nothing; July 29th, 2018 at 04:37 PM.
He who knows not that he knows not is a fool, ignore him. He who knows that he knows not is ignorant, teach him. He who knows not that he knows is asleep, awaken him. He who knows that he knows is a leader, follow him.
July 29th, 2018, 05:15 PM
-
"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.
July 29th, 2018, 05:43 PM
-
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 :-/
Last edited by Triple_Nothing; August 13th, 2018 at 10:21 AM.
He who knows not that he knows not is a fool, ignore him. He who knows that he knows not is ignorant, teach him. He who knows not that he knows is asleep, awaken him. He who knows that he knows is a leader, follow him.
July 29th, 2018, 07:38 PM
-
What version of Dovecot are you running, and what's the contents of whatever conf.d/*.conf file you picked for the SASL stuff?
Comments on this post
July 29th, 2018, 09:04 PM
-
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.
He who knows not that he knows not is a fool, ignore him. He who knows that he knows not is ignorant, teach him. He who knows not that he knows is asleep, awaken him. He who knows that he knows is a leader, follow him.