Jeroen van Aart wrote: > Oliver von Bueren wrote: > >> [EMAIL PROTECTED] 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
