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 188.8.131.52
T 20170227 172636 589df79e EHLO [127.0.0.1]
T 20170227 172637 589df79e RSET
T 20170227 172638 589df79e MAIL FROM:<email@example.com> <--Changed to protect domain
E 20170227 172639 589df79e Host 184.108.40.206 blocked by abuseseat - message rejected.
Here's one that went through:
170227 185114 589df7d2 Connection from 220.127.116.11
T 20170227 185117 589df7d2 EHLO [127.0.0.1]
T 20170227 185121 589df7d2 RSET
T 20170227 185123 589df7d2 MAIL FROM:<firstname.lastname@example.org> <-- Changed to protect domain
T 20170227 185125 589df7d3 Connection from 18.104.22.168
T 20170227 185126 589df7d3 EHLO mail63.morningstar.net
T 20170227 185131 589df7d2 RCPT TO:<email@example.com>
T 20170227 185132 589df7d2 DATA
E 20170227 185132 589df7d2 Closed by GrayWall.
T 20170227 185132 589df7d2 Connection closed with 22.214.171.124, 18 sec. elapsed.
Sadly, hundreds of these went through before I was alerted to the issue.