-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unauthenticated email accepted #286
Comments
Solution would be: If sender domain is a local domain and email was received without smtp authentication - it is subject to antispam (spamassasin). |
In /acl/30_exim4-config_check_mail I did add an ACL which checks for the sender domains (except if mail comes from my local IP ranges). Not sure if this targets the same szenario you have.
I you use this, make sure to have proper IP ranges in the !hosts line. |
I get why you would want and even need an exception for local IPs, but why the exception for local networks though? I'd probably just use Also that |
You are right. !hosts line could be omitted completely. This comes from a time when I had clients (monitoring) on the internal networks which had problems with authentication and I didn't want to exclude each IP separately. Why do you think the logwrite line is an error? |
I guess it could be omitted, assuming emails from localhost are accepted beforehand. Otherwise wouldn't they be rejected by this ACL? EDIT: nope! Commenting it out causes messages to be rejected even when they originate from localhost.
Now that I read it again, I take these words back. However, I'd probably write these messages differently. The And what the BTW, I enabled SPF checking on my server (apparently it was off until now, along with some other checks), and that was enough for my case, because I use strict SPF rules on my domains. Still I think it would make sense for us to ship this ACL too. And it's tempting for me to go set it up for myself too. Gonna do it right now. :) |
So, I set it up and it works, and looks like this:
But now it got me thinking whether this is actually the right thing to do... If my SPF policy prohibits anyone but my own server to send emails from me, this already works. On the other hand, if that policy allows anyone to send emails on my behalf, shouldn't my own server accept them? 🤔 |
Ok. thx for the feedback! And yes, at least !hosts will need something. I believe in "SPF is broken by design" (but please, no discussion about that religion). I just configure it because otherwise I would have a lot of problems with other providers. |
Hmm, weird, I thought I'd copy (and later move) the stock SPF check from But then that check rejects my own emails even if I authenticate first. Which kinda makes sense since there are no exceptions for authenticated users in that check. However, if it stays in |
AFAIR there has been a change in the Debian config in the last years and Debian-Exim uses libspf2.
I don't know why there are two settings for that. I think I use the original file from the Debian bookworm and SPF check is in
|
That's the method I was talking about. I'm somewhat surprised that this check is placed in |
Back in October, I received a funny email in which some great hacker alleged that they had taken over my home network, my mailbox, my everything else, and even caught me on webcam jerking of.
What I found really interesting about that email is that is had my own email address in the From field. I really doubt that the great hacker actually had my credentials, so I suspect that there's a bug somewhere which lets unauthenticated email through if it targets a local mailbox. Would be nice to investigate.
Sadly, I haven't preserved logs from back then. But it should be easy enough to replicate using Telnet.
The text was updated successfully, but these errors were encountered: