logs archiveIRC Archive / Freenode / #exim / 2015 / July / 21 / 1
YmrDtnJu
henk: yes. but i would say "i would like to". is that a problem? i hope not... i just wanted to ask here, if it is possible. its not a big deal ifits not. it was just a simple question.
henk
YmrDtnJu: No problem, I just dont care too much in that case (; Id
phix
hi
henk
hi
phix
:D
rjek
Morning.
R3turn
I'm still receiving too much spam, even with spamhaus,barraucda,spamcop rbl, greylisting and spamassassin enabled. I get like 100 spam messages a day, at least... I can tune spamassassin but the chances of getting false positives will increase dramatically too.
phx
have you enabled SPF on your domains?
also, how have you configured SA? are you just tagging the messages, or actually handling them differently if spam?
R3turn
phx: yes but adding an SPF record won't help for received spam, right? It's about not getting flagged as spammer when sending email?
         

phx
more or less, but it will help
R3turn
phx: I'm tagging them by changing the subject. But only 50% of the messages are tagged, the others have a very low SA score
phx
when someone is sending mail to you over some openrelay, it will get refused due to SPF mismatch
well, tagged messages are still arriving
R3turn
I'm filtering these tagged messages to a separate folder ... Because I wanted to know if there are any false positives in there
phx
personally i have 2 trasholds, N and M, where M > N. if spamscore is > N then i'm moving the mail to .Junk/, if it's >M, then I'm also fakerejecting it
(and it's done by exim+dovecot's delivery agent actually)
other useful side of SPF is, many spammers are sending you mails where the envelope sender and receipients are the same, and you probably will not have the whole china and taiwan in your SPF records, so these messages are just refused
R3turn
the spam messages I receive usually don't have my domain in the from so for these SPF won't help?
anyway, I do have SPF records so it's not anything I can add :)
phx
that's twofolds. if you don't do any SPF checks then surely won't. if you just do SPF checks, but you don't have it on your own domain, then you are checking for the validity of others' domains
right, just then add SPF checks into exim. deny the mails upon spf rejections
henk
R3turn: 100 spam messages does not mean anything without the number of total mails received &
R3turn
henk: 80% is spam
phx
that's fairly normal
R3turn
if that's normal then I'm going to stop using email :p I'm busy removing spam all the time just to find a couple good emails every day :p
henk
R3turn: Are you using a catch-all? i.e. is that 80% for each recipient on each domain or somewhat aggregated?
R3turn
no catch all. All directed to just my email address
henk
hm, maybe you have a config error in there & Can you show some examples from the logs? And maybe some of the spammails? Can you show your ACLs?
R3turn
Would it be wise to tune SA very very sensitive. I know it'll result in a lot of false positives, but it'll filter out a lot of spam too. And then have exim send a message back when it's rejected by spamassassin. That message should containt a captcha image with a number or word and when the sender send that back the email is allowed to pass... So, effectively using a captcha to verify a sender? :)
henk: yes I can
henk
R3turn: There are some parameters that should be tuned in a debian SA installation, but the main thing is turning of the autowhitelist IIRC &
R3turn
here's an example spam mail that passed through SA: http://pastebin.com/Ps6P37ZT
henk
R3turn: That captcha (i.e. challenge-response) idea has been tried and found to be a bad idea for several reasons. You should find the reasoning against it with that keyword (challenge response) in your favorite search engine &
R3turn
henk: I didn't turn off auto whitelisting so I better start with that one already I suppose. Do you know by hard how it's done? Else I'll try to find in google :)
henk
R3turn: Check /etc/spamassassin/v310.pre, AFAICT you just need to comment it there.
         

rjek
I keep meaning to investigate how to get Exim to keep a copy of messages I reject after DATA in case of false-positives and for sending to spamcop etc.
henk
R3turn: But I think it does not have anything to do with your issue. Its just the only thing that came to mind when you asked that & It caused my server to classify a lot more mails as spam than makes sense.
R3turn
okay henk
henk
rjek: fakereject I guess
R3turn
henk: a different spam mail : http://pastebin.com/N4n4LPac .. it even scores 0.0 according to SA
rjek
henk: Doesn't that continue to send the message as it normally would? Ideally I'd just like it to deliver to a local mbox on the MX
henk
R3turn: The first mail you pasted is sent via outlook.com, so RBLs and greylisting wont really help & The content is very little french and a .rtf attachment AFAICT?! Im not sure how well SA can handle either of that &
rjek: Yes, if you only do the fakereject, it will. You will want to do something to deliver the mail to somewhere other than the intended target of course (d
(:
rjek: That second mail is also not english and apart from that looks rather valid too to me & Return-Path and From look sane, even SPF checks out.
R3turn
henk: it looks valid but it's spam. I never received email from that sender, I'm not interested in the content, it just arrived in my mailbox out of nowhere
henk
Maybe someone told them to send you an invite?
R3turn
henk: well, most of the spam email I receive seems valid so ...
everyone is inviting me then ? ;)
henk
maybe (:
R3turn: Another anti-spam measure I employ that seems rather effective is tarpitting.
But that also wont help against spam sent via outlook.com or gmail or some other freemail providers servers &
R3turn
I could try that and see if it helps..
ambrb
hello, can exim be limited to only relay emails from on a list of email addresses?
henk
ambrb: yes
Im not sure I understand the question, but Im pretty sure the answer is yes (:
ambrb
it's for a secondary mx, we want it to only relay emails back to our production server defined by specific email addresses. hope that explains it better :)
it's just to ensure the secondary mail server don't bounce spam
henk
You should make sure your MXs are all using the same setup or the "weaker" will be abused by spammers & Just a general hint. And you probably want to use recipient verification callouts in that scenario &
ambrb
that sounds like a good start
jgh_
either callouts or (possibly preferable) a local copy of the user database - so it's still there when your primary mx system is out
rjek
Secondaries should run identical configuration to primaries, IMO
ambrb
jgh_: i have a local copy of the addresses, just not sure where to impliment this in exim.
rjek: i have not considered this before but it does make sense
henk
maintaining a second copy of the user database adds additional work. Unless there is a good reason to do that IMHO you should really go the callout verification way &
jgh_: Why would you prefer a local copy?
jgh_
to make this MX independent
henk
How does that help?
I can only think of very specific setups and scenarios where that would actually be of IMHO very limited use &
jgh_
you have a secondary MX for HA reasons. Not having it actually available doesn't meed that need
ambrb
the only requirement we have is to have a secondary mx to hold onto mail if the primary server is off. when it goes back on, it should deliver.
rjek
My set up is that our front-end SMTP servers all run identical config and are all of identical priority. They then callout to the back-end SMTP server for checking validity of address
henk
jgh_: But a local copy only covers one single case which is very unlikely in most setups: that the frontend (mx) cannot contact the backend mail server &
jgh_
there's another, imho at least as common case: the primary MX _is_ the mailstore system; no separate backend
ambrb
we run exim and dovecot on the same vps if that helps?
jgh_
(and I'm unsure why you think the backend can never go out, either)
henk
Well, my point is: the secondary will just receive those mails and put them in the queue. What does that help anyone?
jgh_: Im not saying it will never go out, but if its out (or unreachable) then what does it help when the MXs still receive the mail? It cant be delivered to the backend anyway &
jgh_
they have progressed in the mail store-and-forward chain. This is what secondaries are for. If you don't care, and want to force all mail originators to queue until you primary(s) return to life, fine. Why are you running a secondary again?
henk
btw: the callout results will be cached, i.e. even if the backend goes away, the callout-method will still receive most mails for quite a while.
rjek
The trick is to mark that callout rule as deferable :)
henk
power, network, hardware redundancy
ambrb
so to recap ...
rjek: what if your backend is down?
how does it validate the address?
rjek
ambrb: Results are cached, and it has defer=ok
deny !verify = recipient/defer_ok/callout=10s,defer_ok
ambrb
in our case, the secondary server would only be utilised in primary is off which would also mean dovecot is off. how would the secondary be able to validate the recipient or in this case, be able to cache results?
im also really open to suggestions, as you can see, my experience here is very limited and i really appreciate everyones input
rjek
recipient verification, as above
jgh_
... until a spammer deliberately targets the 2mx, for a recipient that hasn't been seen before and doesn't exist, and the primary is down. Then you're a backscatter source
rjek
The messages just get frozen
henk
Id leave out the defer_ok and just have the sender try again later until the backend is up again &
ambrb: You cant tell senders (especially not spammers) when to use which MX. And since a lot of setups do _not_ follow the rule "all MXs are equal" spammers tend to try the "secondaries" first because their anti-spam measures are usually less evolved &
ambrb: If the backend server (be it another MX or a dedicated and possibly hidden server) is gone and the MXs cannot verify the recipient, they also can not deliver the mail but have to queue it. Thats more or less useless in most cases, so it doesnt really matter whether it can verify the recipient. IMHO.
ambrb
henk: I understand and it makes perfect sense. where this has been a problem for us is when (and yes, it happens very seldomly), our primary server is down we get a lot of angry clients worried that they would not be able to get emails during this period (or that emails would be undelivered). we're just trying to setup a solution that should our primary server go down, we have another server...
...in place to catch all incoming emails
not so much worried for outgoing as they would not be able to send emails anyways as dovecot would be off anyways
it's purely just a safety precaution to ensure that worst comes to worst, we have something in place to catch your incoming emails when our datacentre is down / out
« prev 1 2 next »