efa-project.org

In reference to the ingenious article here: viewtopic.php?f=14&t=1278

While working on the logistics to implement this solution, I ran into a catch with Google. We have Google handling our student email accounts, and as such, we have several internal users as 'owners' for a few student groups. This usually wouldn't be a problem but it's thrown a wrench into the article above:

If internal user a@domain.edu sends an email to a student group studentgroup@studentdomain.edu (hosted by Google) it also gets relayed back to the 'owner' users x@domain.edu y@domain.edu z@domain.edu (hosted by us) with the message being from a@domain.edu - these relayed messages flow from Google back to us through EFA. This scenario is partly what the article above is attempting to prevent - internal domain spoofing for incoming mail.

I ran a test, and found that virtually every inbound message from Google is sourced from a different IP - when the exact same message is relayed back to x y and z above, each of them comes from different IPs! Google specifies that the best way to find their IP addresses is to query their SPF record: https://support.google.com/a/answer/60764?hl=en


Is there any practical way we can add some additional logic to these filters, so it can still allow incoming messages coming FROM a@domain.edu, so long as it was sent TO studentgroup@studentdomain.edu ?

Thanks for any suggestions!


(edited to clarify some points)

Wow, I see the problem. Not sure to handle it, though...

Anything special in the headers on the emails coming back from Google? Maybe somehow header information could be used to perform a header check in postfix?

(Sorry, I forgot I posted this last week!)

The outbound messages do come from our Exchange server, so there are Received: headers indicating it originated on our network. I have far too little experience with the powerful features available in *nix. Unfortunately.

I would be happy to provide a sample if it might be helpful!

Can you share what one of the headers look like? I think I have a possible solution...

Attempted to send via email. Please let me know if you need anything else!

Can you send a PM, sorry, my spam trap is just a spam trap...

Sent. Thank you again for your assistance!

A possible solution...

Since you already trust these emails from Google groups, why not perform a postfix header check to bypass everything...

/etc/header_checks Wondering if this would work...

After looking at it, the syntax doesn't look correct, but that is certainly how Google is tagging them. Odd, but then again, that is Google! I have it in place and will check it when we implement the other rule(s) as mentioned above. I'll try to remember and update this post after it is in place.

For anybody looking for the file, I found it located in this location - I'm still learning *nix file system layout and related concepts myself: Thank you much, Shawniversion!

Keep me posted. Not sure if this setting takes precedence or not.

I have a few more ideas, such as using DKIM and DMARC instead of using smtpd_restriction_classes

has dmarc been implemented in the current EFA version or is it somewhere on the roadmap?

I went through the mail list. Here are my thoughts

a) configure via postfix, might cause problem during next upgrade, and I have no visibility
b) so I published SPF records for my own domain
c) change the default score for SPF_FAIL for spammassin to 4.0, and that will mark it as spam

this way, I get to see which accounts are being scoffed...

I'm already using SPF + DKIM + DMARC for all the domains I handle email for but I'm asking about the reverse: SA is already checking SPF and DKIM but how does one then implement/handle incoming email according to the sender's published dmarc record? (I'm pretty sure I can find an article which implements that via postfix but ideally I'd like to see this implemented via EFA itself).

After reading about dmarc some more it seems it is really advisable to be done in the MTA via i.e. a milter.
If one is looking to do this in SA here are some nice read-ups:
https://blog.laussat.de/2014/05/19/usin ... massassin/
http://search.cpan.org/~msimerson/Mail- ... l/DMARC.pm

I finally got a chance to implement this as a test. My guess about incoming mail not coming through when relayed back was correct - they are denied. The work-around suggested above did not work.

What we did not anticipate was it entirely preventing email from the student domain. I'll have to get you a copy of the message headers for a good message, and the reject when this is enabled.

For now, all of the files/settings are in place. I just switch a comment between two lines in main.cf, then restart postfix.

I'm guessing given your environment that using the above howto isn't going to work in your specific use case.

However, if you implement DMARC as a milter, as well as DKIM milter and publish appropriate DKIM, SPF, and DMARC records, you may find that the spoofing will not occur and you will be able to email successfully between both systems.