You should check all the boxes and that will only allow users that have a password to send email. The only hole in the system (might be) that they are not all checked by default.
The way I have Pegasus/Mercury set up for my client is that no one can send email outside the system. I have it set that 2 IP addresses within the system can send to/through Mercury (a backup and the voicemail system} without a password. This has worked perfectly for the 18 years I've used the system...until now. What I have discovered is if someone outside the system announces themselves as EHLO [127.0.0.1] and the actual connecting IP isn't on a blacklist, they can spoof and send mail on behalf of an actual user through Mercury to their heart's content. I've applied the bandage of putting the domain on the kill list as I've not figured out how to stop it at the transaction level, but I think this is a HUGE exploit that needs a plug immediately.
Here's a log entry:
170227 172635 589df79e Connection from 1.255.70.123
T 20170227 172636 589df79e EHLO [127.0.0.1]
T 20170227 172637 589df79e RSET
T 20170227 172638 589df79e MAIL FROM:<user@ourcompany.com> <--Changed to protect domain
E 20170227 172639 589df79e Host 1.255.70.123 blocked by abuseseat - message rejected.
Here's one that went through:
170227 185114 589df7d2 Connection from 77.201.28.3
T 20170227 185117 589df7d2 EHLO [127.0.0.1]
T 20170227 185121 589df7d2 RSET
T 20170227 185123 589df7d2 MAIL FROM:<user@ourcompany.com> <-- Changed to protect domain
T 20170227 185125 589df7d3 Connection from 216.228.237.32
T 20170227 185126 589df7d3 EHLO mail63.morningstar.net
T 20170227 185131 589df7d2 RCPT TO:<user@posterman.top>
T 20170227 185132 589df7d2 DATA
E 20170227 185132 589df7d2 Closed by GrayWall.
T 20170227 185132 589df7d2 Connection closed with 77.201.28.3, 18 sec. elapsed.
E 20
Sadly, hundreds of these went through before I was alerted to the issue.
On the General tab of the SMTP module you should have the relaying controls checked. On the Compliance tab edit the transaction file and add the line
H, "*127.0.0.1*", R, "554"
See how that works.
Do you use a mail filtering service? If so, you can add a line that will only accept connections from that filtering service's address.
Thanks! The expression worked. I simply do not want to allow any outside relaying of email. I still think this is a hole that needs plugged.
According to the log excerpt the second connection was closed by GrayWall, but perhaps the sender retried until it was accepted.
The main thing is to make sure relaying settings and connection control entries in MercuryS configuration limit relaying the way you want it. Connection control checks the connecting IP address, and it won't make any difference what the HELO/EHLO greeting says.
As I stated in my original post, I do not allow relaying outside of the network at all. No one can send email through POP3 or IMAP. I don't allow offsite relaying. Period. Two IP addresses in the NAT are allowed to send email through Mercury bypassing Pegasus, but they are Pegasus users. I've been using this setup for 18 years (Mercury for far longer) with this particular client with no one defeating it and I'm telling you the EHLO [127.0.0.1] with a local user email address defeats the system. Yes, Graywall did shut this particular attempt down, but I have HUNDREDS that I pulled from the queue that were persistent enough and not on abuseat that did get through. I think the 127.0.0.1 coupled with an actual local user is causing a problem because Mercury thinks the connection is local.
You should check at least "Use strict local relaying restrictions", and you should probably consider checking "Only Authenticated SMTP connections may relay mail". See Mercury help for more information about these options!
