no spf checks for authenticated users, relaying and private ip's

[ghost]

I have one question regarding the SPF plugin. As far as I can see, spf checks will be done when I send email as an authenticated user for relaying.

In my opinion, no spf checks should be make for authenticated users(connection.relaying=true, set by auth/auth_base.js) because the remote ip will never match spf records and always fail.

The same goes for relaying from authenticated smtpd's - like when I run an "external" company mailserver which receives mail from other "internal" company mailservers for relaying (connection.relaying=true, set from the relay.js and relay_acl.js plugins).

Concrete, I am talking about these lines of code

plugins/spf.js, line 114-117

 if (!connection.relaying &&
   net_utils.is_private_ip(connection.remote_ip)) {
   return next();
 }

Should IMHO look like this

if (connection.relaying ||
  net_utils.is_private_ip(connection.remote_ip)) {
  return next();
}

or do I miss something here?

Thanks, Marc

[ghost]

reference: http://www.openspf.org/FAQ/Common_receiver_mistakes

[msimerson]

or do I miss something here?

You are missing something. Read the rest of the exports.hook_mail function and pay careful attention to the context and my_public_ip stuff. Report back here if you still don't grok it, or if you have an "aha" moment. Suggestions on how to make that code more obvious are welcome.

[msimerson]

spf plugin docs

[ghost]

Thanks for the advice and the hint to the context. I set the context to "myself' (external ip detection does not work for me though - I have a complex smtp setup w/ tunnels, so always the client ip is being used), but even then a SPF header is added to outgoing mail when I deliver as an authenticated user and it's always a FAIL (in my case), which has negative impact to spam detection (spamassasin, etc).

What I don't grok is why a SPF check has to run and a SPF header has to be added when an allowed relay server or an authenticated user sends outbound mail :) Why not just skip it as suggested? I'd assume that SPF checks should only run on the mail receiver side and not "in advance" when sending outbound mail.

[msimerson]

Imagine you have a mail server running Haraka. Imagine that you have human users relaying through your Haraka. Imagine that a user password(s) get compromised. Imagine that your Haraka server is now effectively an open relay for whomever just compromised their password(s). Image that you wish to reduce the collateral damage them miscreants can wreak upon your server.

Setting context=myself and validating SPF against your own public IP will now reflect a SPF failure when the miscreant attempts to send 10,000 emails from @freemail.com domains.

[msimerson]

Also, you can manually specify your external IP. Then just make sure domains with permission to relay include your mail servers public IP in their SPF records.

The long and short of it is, Haraka should not accept emails (even relayed) if the destination MX is likely to SPF=fail it.

[ghost]

In order to recognize SPF, the receiving smtpd has to implement SPF and do checks by his own for each incoming mail anyway. So it makes no difference if my mail-sever is pro-active and add's a SPF header to outgoing mail, because the receiver does it's own checks and makes decisions based mainly on that, not on what my mailserver wrote to the header.

I've manually set the "public_ip" in smtp.ini - thank you for the hint! The SPF check is now a PASS (for mailfrom) and a NONE (for helo) - anyways - I don't see any benefit of being pro-active for authenticated/authorized outbound mail. But maybe it's just me :)