Re: [exim] Preventing Sender Forgery .

Jeroen van Aart wrote:
> Oliver von Bueren wrote:
>
>> JDavila@??? wrote:
>>
>>> How can I prevent Sender Forgery for my server. Alot of people in my
>>> company are getting e-mails from themselves. Any Ideas will be greatly
>>> appreciated.
>>>
>>>
>> Only allow local domains to be used on authenticated SMTP sessions on
>> the submission port. I'm doing this here since a long time with no
>>
>
> You can't really stop forging the From: that way. Neither will SPF stop
> forging email headers. Nothing really will, except a total redesign of
> the smtp protocol or a totally new protocol.
>
As I wrote in my mail, this is only a small portion of what I do in my
set up to prevent this kind of attack. And for this discussion, I only
wrote about the checks on the SMTP sender/recipient level, content
scanning of the message, to which the From: / To: headers ultimately
belong to, is an entirely different topic in my configuration and for
obvious reasons not in the RCPT acl.
BTW: local_domains includes all domains for which I handle mail and have
control over, meaning the final MX destination is within my set up.

This part of the configuration only prevents simple spam senders to use
the MAIL FROM of the destination user (or any local user for that
matter), as is often done. This trick gets rid of a lot of simple Spam.
And, as you see from the original message, many systems treat mail sent
with a local_domains sender address in a way to just pass it. After
implementing this very simple step, which should be in place on a server
reachable from the internet anyway, otherwise you are an open relay,
you have to make sure that some basic or more extensive checks of the
sender address are performed, e.g. check the existence of the sender
domain, may be do callout verification for the sender, use RBLs, ....
Please note, these are all checks done on the way to accepting at RCPT
TO so more expensive checks at the data stage can be prevented because
the message gets rejected early on!

So my simple policies for accepting mail are:
0. HELO/EHLO abuse
1. Never relay mail without AUTH
2. Prevent abuse of local_domains as sender, only allow on AUTH sessions
3. RBLs, ...
4. Sender verify
5. Content analysis (might be SA, but can be simpler stuff as well)

0-4 generate deny at RCPT TO, 5 at DATA. Messages getting through will
be delivered as they have been accepted into the system in the first
place. Tagging might mark these as SPAM, though.

Oliver