Forged Email problems

larslar

Verified User
Joined
Aug 29, 2006
Messages
9
Location
Minneapolis
I am having issues with my DirectAdmin installation. It would appear that anybody knowing a valid domain hosted on the system can send messages to a valid recipient with a forged from field.

For example, a malicious sender looks up the MX for domain.com and it points to my DA server. The sender connects to the mailserver and sends an email message from [email protected] to [email protected] and it is delivered.

This is not an open relay because it will not let you send outside of the server, but needless to say, this is annoying our email customers.

Should I enable authentication for senders in Exim? I though POP before send was the DA way?

Any advice would be most welcomed.
 
I think the problem lines in the exim.conf looks like this:
Code:
# accept if address is in a local domain as long as recipient can be verified
  accept  domains = +local_domains
          endpass
          message = "Unknown User"
          verify = recipient
# accept if address is in a domain for which we relay as long as recipient
# can be verified
  accept  domains = +relay_domains
          endpass
          verify=recipient
it is found right after all the spam deny messages. I have not tried removing them yet, because I have only seen this happen once so far, and haven't had the time to test it thoroughly.
 
i have the same lines:

# accept if address is in a local domain as long as recipient can be verified
accept domains = +local_domains
endpass
message = "Unknown User"
verify = recipient

# accept if address is in a domain for which we relay as long as recipient
# can be verified
accept domains = +relay_domains
endpass
verify=recipient

I think the problem lies more in the sender verification than recipient verification.
 
Perhaps these lines are culprit? Is this correct in the exim.conf file?

hostlist relay_hosts = net-lsearch;/etc/virtual/pophosts : 127.0.0.1
hostlist auth_relay_hosts = *


accept hosts = +relay_hosts
accept hosts = +auth_relay_hosts
endpass
message = authentication required
authenticated = *
deny message = relay not permitted
 
perhaps add the lines
Code:
 endpass
message = authentication required
authenticated = *
deny message = relay not permitted
directly after the
Code:
 accept hosts = +relay_hosts
line. That way it should request authentication even if the apparent source domain is local.
 
I do not think this is correct. The relay_hosts looks fairly secure, it is the auth_relay_hosts I am concerned about.

To be a relay_host you already have to have successfully POP'ed something, so you are legitimate.
 
Look at the definition though:

hostlist relay_hosts = net-lsearch;/etc/virtual/pophosts : 127.0.0.1

vs.

hostlist auth_relay_hosts = *

There is no way that anybody can just end up in relay_hosts without an implicit definition or appearing in the /etc/virtual/pophosts file. Anybody can be in the auth_relay_hosts because of the wildcard.
 
I think my authenticators are probably broken :(

begin authenticators

plain:
driver = plaintext
public_name = PLAIN
server_condition = "${perl{smtpauth}}"
server_set_id = $2

login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = "${perl{smtpauth}}"
server_set_id = $1
 
I just uncommented the following line:

require verify = sender

and it now blocks mail being sent from an [email protected]. I can however choose a legitimate user and send mail to that user with out authentication.

for example, i can connect without being in the pophosts or authenticating and send a message to

[email protected] from [email protected]

It has to be the authentication that is broken.
 
It is not coming from 127.0.0.1, it is coming from an unknown IP address.

Authentication seems to work. I've been testing it. It must reside in the ACLs.
 
Back
Top