SPF check of incoming mail

[Mati]

I have been using 'SPF check of incoming mail' on the other control panel - it was causing no problems and stopping a lot of spam (because of the fact that spammers like to pose as somebody else) and new viruses.
Exim support SPF so it could be easily implemented in DA.

Thank You,
Mati

 

[nobaloney]

The last time I read the SPF site they admitted that it broke forwards. Can you show us that forwards (from someone outside your server, to someone on your server checking for SPF) is no longer broken?

Do you recommend blocking completely? or setting a point level? If the latter, then it needs to be done in SpamAssassin and not in Spamblocker.

I looked for SPF suport at the exim.org site and found a link to the spf site's download page, but on that page there was nothing for exim.

Do you, or does anyone else, have a copy of the exim.conf file from what you call the other control panel which shows spf functionality?

Jeff

 

[Mati]

The last time I read the SPF site they admitted that it broke forwards. Can you show us that forwards (from someone outside your server, to someone on your server checking for SPF) is no longer broken?

It was resolved very very long ago by using SRS.

Do you recommend blocking completely? or setting a point level? If the latter, then it needs to be done in SpamAssassin and not in Spamblocker.

Many people do not use SpamAssasin because it causes some problems.
The other thing: SPF should be earlier, before mail body examining.

 

[nobaloney]

What is SRS? Does it resolve a problem with forwarding (don't forget that DirectAdmin uses forwarding and many users with DirectAdmin solutions and other solutions also use forwarding. Or does it replace forwarding? In which case it's not a solution until everyone uses it.

If SPF is used before mail is accepted on the server, then the only way to use it is to block completely or to create a scoring system to be used in ACLs; a scoring system similar to that used in SpamAssassin. I don't feel qualified to decide on implementing a complete scoring system for exim. Do you? If blocking completely than both forwards and mailing list email may be blocked.

You may know more than I do. Please direct us to links so we may begin a real discussion on this.

Or alternatively, there's nothing that says you can't write your own exim.conf file, or write one for the community, as I have done.

Thanks.

Jeff

 

[Mati]

SRS:

http://www.openspf.org/SRS

Every well fixed server should use SRS because the forward mail from this server would be blocked by majority of servers (because majority of servers use 'SPF check of incoming mail').

I do not know how to implement SPF in exim.conf because I used Qmail before but if You are in Exim maybe it is worth of your attention (it really block many spammers pretenting to be someone else).

PS
Using 'SPF check of incoming mail' does not require 'scoring system' because We should block everyone who pretends to be somebody else (for sure he is a spammer or a viruses sender)

 

[nobaloney]

The issue is that neither DirectAdmin nor most other servers have replaced forwarding with SRS.

From the page to which you link:

but there is a source patch for libsrs2, which also supports Sendmail and Exim.

This is not enough information for me to figure out what to do to make exim support SRS, and then even once it is implemented, DirectAdmin staff would have to make perhaps extensive changes to DirectAdmin.

Hopefully DirectAdmin staff will read this thread and get involved.

You wrote:

Every well fixed server should use SRS because the forward mail from this server would be blocked by majority of servers (because majority of servers use 'SPF check of incoming mail').

This is simply not true; if the majority of servers were blocking forwards, then we couldn't use them. And many of our clients use them.

And then what about mailing lists? Does Majordomo implement mailing lists in a way that is SPF compatible?

Of course whether or not we allow using of forwarders and Majordomo mailing lists to send mail doesn't necessarily mean we can't refuse forwarded mail and Majordomo mailings; it just seems a bit hypocritical.

Comments from others welcome.

Jeff

 

[zEitEr]

SpamAssassin can do SPF check. There are tests (AREA TESTED DESCRIPTION OF TEST TEST NAME):

header 		SPF: sender matches SPF record 	SPF_PASS
header 		SPF: sender does not match SPF record (neutral) 	SPF_NEUTRAL
header 		SPF: sender does not match SPF record (fail) 	SPF_FAIL
header 		SPF: sender does not match SPF record (softfail) 	SPF_SOFTFAIL
header 		SPF: HELO matches SPF record 	SPF_HELO_PASS
header 		SPF: HELO does not match SPF record (neutral) 	SPF_HELO_NEUTRAL
header 		SPF: HELO does not match SPF record (fail) 	SPF_HELO_FAIL
header 		SPF: HELO does not match SPF record (softfail) 	SPF_HELO_SOFTFAIL

http://spamassassin.apache.org/tests_3_3_x.html
http://wiki.apache.org/spamassassin/Rules/SPF_NEUTRAL

Just set your scores for the tests.

 

[Mati]

SpamAssassin can do SPF check.

Yeah, we know. But 'SPF check of incomining mail' should be before email body examining. That is why it should be in exim.conf. Maybe somebody has practice on it with Exim - please write here.

 

[LawsHosting]

Yeah, we know. But 'SPF check of incomining mail' should be before email body examining. That is why it should be in exim.conf. Maybe somebody has practice on it with Exim - please write here.

This has been discussed many times before i.e the email sub-forum

 

[nobaloney]

The big issue for me is still forwards and mailing lists. As long as people are using them (and many people are) SPF doesn't work unless to set a score, to be considered with other scores, and in my opinion that's best done in SpamAssassin.

Of course Mati and anyone else can certainly make his/her own changes to exim.conf; perhaps even fork my work and maintain it, or pass it on to DirectAdmin staff for inclusion.

Jeff

 

[Mati]

The big issue for me is still forwards and mailing lists. As long as people are using them (and many people are) SPF doesn't work unless to set a score, to be considered with other scores, and in my opinion that's best done in SpamAssassin.

If a forward emails will come from a server with no SRS implementation also Spamassassin on target server will treat it as a SPAM (Spamassassin will treat these good emails the same as if these ones were sent by spammer pretenting to be somebody else). That is why in my opinion well fixed server should use SRS. I would like to have blocked these emails before body examining in exim.conf but even DA users using Spamassassin (many people using Spamblocker do not use Spamassassin) are having these non-SRS modified emails blocked.

 

[nobaloney]

You quoted only part of my post. You didn't quote the part that said you or anyone else is welcome to make the change.

We both send and receive forwarded email. As do many of our clients. Many of our clients forward email to their accounts at major ISPs and they get them. So I'm not sure what you mean about SRS being reauired or the email will be treated as spam.

You write about your opinion and of course you're entitled to your opinions, but if the rest of the world ignores them, then my servers must work in the real world, not the world of your opinion.

How would you block these emails emails without examining them? What specifically would you look for in the smtp protocol exchange on which to base blocking?

Jeff

 

[Mati]

So I'm not sure what you mean about SRS being reauired or the email will be treated as spam.

I meant that if the mail will be forwarded by the server with no SRS then it will be blocked by the target server with SPF check (if the target server does that check).

You write about your opinion

My opinion comes from the logic. This is logical that server is better fixed when it supports SRS. SRS only causes (by changing headers of forwarded emails) that the forwarded mail from the server will not be blocked by the targer server configured to do SPF check. From that reason my opinion is that server with SRS is better fixed server than the server without it.

 

[nobaloney]

Mati,

This thread is in the Feedback and Feature Requests subforum, and yet no one except for you and I have gotten involved in the discussion.

It doesn't appear that anyone else is interested in SRS one way or the other. Hopefully if some other readers are, then they'll join the discussion.

If not, then here are my last words on the issue:

SRS: If you want it either talk DirectAdmin staff into doing it, or write it yourself as a plugin. But if you do, remember that it needs to not only be implemented into the forwarding code but also into Majordomo (for mailing lists).

SPF: It's easy enough for you to implement it in your own exim.conf file. You don't need me for that. You're certainly free to write the DirectAdmin staff (see link above) and let them know that you think I'm out of touch with reality and that they should rewrite exim.conf themselves. Or you can write one for them, which manages SPF. or you can just write it for yourself. Or you can pay someone else to write it for you.

Before you do I suggest strongly that you try running the latest SpamBlocker-Powered exim.conf file, Version 4 (find it here (nobaloney.net); for us it blocks almost all spam.

And you might want to check with the author of SPF and see if he recommends it as an anti-spam solution. I know that years ago (when I went to one of his presentations) he didn't.

Jeff

 

[Mati]

Mati,
SRS: If you want it either talk DirectAdmin

I thought that I have done it already writing about it on this thread. This is "Feedback and Feature Requests" forum.

SPF: It's easy enough for you to implement it in your own exim.conf file.

I have written already on this thread that I can not do it. That is why I reported it on "Feedback and Feature Requests" forum.
The other thing: I do not want to have it only for myself. I want to share my ideas to make standard Direct Admin better for everyone.

You're certainly free to write the DirectAdmin staff (see link above) and let them know that you think I'm out of touch with reality and that they should rewrite exim.conf themselves.

I have never written anywhere that You are out of touch with reality .
It is even ridiculous because actually it's You who have written it about me (not I about You) commenting my opinion that well fixed server is the server with SRS.

 

[Swift-AU]

Add the following to your check_recipient ACL in exim.conf

drop message = [SPF] $sender_host_address is not allowed to send mail from $sender_address_domain
log_message = SPF check failed
!authenticated = *
set acl_m9 = --scope mfrom --id $sender_address --ip $sender_host_address
set acl_m9 = ${run{/usr/bin/spfquery $acl_m9}}
condition = ${if eq {$runrc}{1}{true}{false}}

Grab spfquery from here if you don't have it.

 

[nobaloney]

@Swift-AU:

Am I correct in my understanding that if you install this it'll do a check on SPF only if the sender has an SPF record?

And then if you do a drop entirely on SPF check, then if there's an error in SPF you'll refuse the mail, but if there's no SPF you'll still get the mail?

If so, then the only thing you have to worry about is you may be blocking a lot of forwards and mailing lists. Not everyone uses SRS. For example anyone using DirectAdmin doesn't.

Can your exmple be used only with certain senders? How? For example, we might want to add well-known banks, PayPal, ebay, and others often spoofed in email phishing attempts.

And if you or someone else will show us how to add SRS to our exim configuration, I'll consider adding it, depending on how easy it may be.

Jeff

 

[Swift-AU]

Hi Jeff,

It will do the check irrespective, but naturally spfquery won't repond with a "fail" for a domain that doesn't have an SPF record in place. Only a matching "-all" (hard fail) will cause Exim to drop the message.

I don't see why any properly configured mailing list would be affected, as it should have the "MAIL FROM:" correctly rewritten. Some forwards no doubt could be blocked, but in the two years or so I've been dropping messages failing an SPF check, nobody has complained! The one problem I do notice is that some companies (and government departments in particular) haven't listed all the IPs they send messages from in their SPF record and yet have set the policy as "-all". Naturally this means some of their legitimate e-mails get rejected (and rightly so!)

Admittantly the SPF check only rejects a small percentage of e-mail compared to what Spamhaus DNSBL checks (and others) catch, but it's certainly better than nothing.

You could easily restrict the SPF check to certain domains, but I think it would tend to defeat the purpose and make it not worth while for the amount of SPAM it would trap. If there was really a need to implement SRS I would consider it, but doing this on your own MTA only fixes one side of the equation. It wouldn't make any difference to the SPF check added in Exim on your own server, because that would rely on the "MAIL FROM:" having been rewritten at the server that forwarded the e-mail in the first place.

-Swift

 

[nobaloney]

At last the beginning of a dialogue on this.

It will do the check irrespective, but naturally spfquery won't repond with a "fail" for a domain that doesn't have an SPF record in place. Only a matching "-all" (hard fail) will cause Exim to drop the message.

As far as your example code is concerned, what's the difference between ~all and ?all? Does it treat them both the same?

I don't see why any properly configured mailing list would be affected, as it should have the "MAIL FROM:" correctly rewritten.

That information came from the author of SPF quite some time ago, at the conference I mentioned.

Have you checked to see what majordomo, as used by DirectAdmin, does?

Have you checked other mailing lists to see if they're correctly configured? I just checked four mail lists to which I'm currently subscribed, and which use the author's email address in the From field. None of them have MAIL FROM configured. Am I missing something? Or would these all fail if the original sender had spf configured with -all?

Some forwards no doubt could be blocked, but in the two years or so I've been dropping messages failing an SPF check, nobody has complained! The one problem I do notice is that some companies (and government departments in particular) haven't listed all the IPs they send messages from in their SPF record and yet have set the policy as "-all". Naturally this means some of their legitimate e-mails get rejected (and rightly so!)

rightly so from your point of view as the admin, but what happens when you tell your client they didn't get an important piece of email because the sender got it wrong? Or do you couch it in such a way that they don't know you have a choice of accepting the email or not?

Admittantly the SPF check only rejects a small percentage of e-mail compared to what Spamhaus DNSBL checks (and others) catch, but it's certainly better than nothing.

Is it? The author of SPF has said to never block email based on SPF, but only use it as part of a scoring something. It seems that he considers using it to block is not better than nothing, but rather worse than nothing. Has he changed his mind? If so, show me where.

If he hasn't changed his mind, then checking it in SpamAssassin is where it belongs.

You could easily restrict the SPF check to certain domains, but I think it would tend to defeat the purpose and make it not worth while for the amount of SPAM it would trap.

The only way I'd ever consider using it would be for banks. Right now the SpamBlocker-Powered eixm.conf file i distributel blocks PayPal phishing attempts, but not from other banks, because I can't be sure what mailservers they may use. But if I could get a list of banks that publish correctly configured SPF I might want to check it only for those banks. Again, to eliminate phishing attempts, which is what SPF was designed to do.

If there was really a need to implement SRS I would consider it, but doing this on your own MTA only fixes one side of the equation. It wouldn't make any difference to the SPF check added in Exim on your own server, because that would rely on the "MAIL FROM:" having been rewritten at the server that forwarded the e-mail in the first place.

Which as I've shown, isn't happening.

Nevertheless, wouldn't it be hypocritical to check fix only one side (receiving) without the other (sending)?

What else am I missing?

Jeff

 

[Swift-AU]

Hi Jeff,

Check the e-mail address in the "Return-path:" line of messages coming from mailing lists. This is the address that was communicated in the "MAIL FROM:" command when the message was sent to your SMTP server, and which will be used for SPF checking.

As I mentioned previously, only a "-" will reject a message. "? and "~" and "+" will be passed. Any domain owner who doesn't want their messages to be blocked through the use of their SPF record, should not be using the "-" fail syntax. Rather, they should be using "~" softfail. The SPF specification is very clear about this. It has nothing to do with only using SPF results as a weight to be combined with other SPAM checks.

My clients are happy with the reduced volume of SPAM, and whenever an example comes to my attention I make it a point to contact the relevant admins advising them of the error in their SPF record. Naturally it's up to them whether or not they bother to fix it.

If everyone took the attitude that we shouldn't implement a particular measure to combat SPAM because a small percentage of legitimate messages may be blocked, then the world would have a helluva lot more SPAM! Everyone I've talked to (excepting your good self) is happy in knowing they are doing their bit to make the (internet) world a better place.

-Swift