Spam over SPF

[MtK]

Hey,
one of the domains on our servers as this SPF record:

v=spf1 a mx include:_spf.google.com ip4:{SERVER_IP} ~all

(yes, it is a Google Apps account)

the problem is that somehow, email are sent from an external server/spammer with this header:

X-PHP-Originating-Script: 1191:mail.php(2) : eval()'d code
From: '<[email protected]>
Reply-To: [email protected]

how is this possible and why does the SPF doesn't prevent that?

 

[scsi]

Lol spf only says if an ip is allowed to send mail from that address and most the time spf isnt even really looked at. You are also using a softfail. I consider you switch to hard fail if you want to prevent external ips from sending. How are you getting this mail anyways? If they are relaying through your server spf wont even stop it.

http://en.wikipedia.org/wiki/Sender_Policy_Framework

 

[MtK]

Lol spf only says if an ip is allowed to send mail from that address and most the time spf isnt even really looked at. You are also using a softfail. I consider you switch to hard fail if you want to prevent external ips from sending. How are you getting this mail anyways? If they are relaying through your server spf wont even stop it.

http://en.wikipedia.org/wiki/Sender_Policy_Framework

apparently those emails are being sent from a GMAIL account (!).

I'm not getting them myself.
I know about them because the Reply-To address is of a domain in our servers, but that actual email address doesn't exist.

 

[MtK]

btw, isn't ~all in DA's template?

 

[Richard G]

Yes, ~all is in DA's template. You could manually change it to -all if indeed al systems which are sending mail for you are mentioned in the SPF line.
Other systems which check SPF records will then indeed refuse mail not coming from your system. However, there are still lots of systems out of there not doing any SPF checks, so they will still be receiving the spam mail.
Probably somebody is spoofing your domain name using fake email adresses in the reply-to line.

 

[MtK]

this email spoofing was apparently sent from a (personal) GMAIL account, so just to understand, even if I use -all which should prevent anyone which is not specifically allowed to send emails, spoofing will not be prevented?
and specially from within GMAIL...?

 

[nobaloney]

The are lots of problems with the hardfail (-all) setting, including that your users then cannot send email from their ISPs mailserver. And if your user is using Google Mail/Gmail, there must be both their information and your server IP# in the record, or else forwards, autorespondes, etc., may fail or end up in spam mailboxes.

DirectAdmin defaults to softfail (~all) because it's the safest setting in a shared-hosting environment where you don't know what mailserver your users may be using to send email.

Jeff

 

[MtK]

The are lots of problems with the hardfail (-all) setting, including that your users then cannot send email from their ISPs mailserver. And if your user is using Google Mail/Gmail, there must be both their information and your server IP# in the record, or else forwards, autorespondes, etc., may fail or end up in spam mailboxes.

the spammer/spoofer is a GMAIL user, but not related to this Google Apps account.
he sent from his private [email protected] mail and not [email protected].

DirectAdmin defaults to softfail (~all) because it's the safest setting in a shared-hosting environment where you don't know what mailserver your users may be using to send email.

so how do I prevent the case I have?

 

[nobaloney]

This thread reminds me of a meeting I attended many years in San Jose, Caliofornia, where the inventor of SPF was presenting it for the first time.

SPF is not designed to protect against spam. It's a tool designed to prevent spoofing, but it only works in the strict mode if you control all the places from which an email can be sent. Years ago I recommended the softfail to DirectAdmin publishers since you don't really know if a user is going to use his provider's outgoing SMTP server, in which case the strict setting would cause a failure. Or in worst cases, years ago, many ISPs would simply redirect all outgoing email through their servers no matter what the user settings were, so they could track email usage.

These days as long as your users have 587 set as their port, the outgoing email should make it to your server, but they still need to worry about all sorts of other problems. For example, how does your form-to-email script work? Does it send from your server (likely) but with the from address your user types in, to facilitate a return? Many do, and if yours does, remember that the email would appear to the recipient (you?) as coming from one domain, but from an IP# not in that domain's SPF setting.

And how about forwarding. There have been lots of discussions on this; some say SPF is broken, others say forwarding is broken and shouldn't be used. Suffice it to say that when forwarding is used the SPF probably doesn't match the domain in the From address, so a softfail is a requirement.

Jeff