Preventing Domain Spoofing - Problem With A Twist?
Preventing Domain Spoofing - Problem With A Twist?
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)
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)
- shawniverson
- Posts: 3649
- Joined: 13 Jan 2014 23:30
- Location: Indianapolis, Indiana USA
- Contact:
Re: Preventing Domain Spoofing - Problem With A Twist?
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?
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?
Re: Preventing Domain Spoofing - Problem With A Twist?
(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!
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!
- shawniverson
- Posts: 3649
- Joined: 13 Jan 2014 23:30
- Location: Indianapolis, Indiana USA
- Contact:
Re: Preventing Domain Spoofing - Problem With A Twist?
Can you share what one of the headers look like? I think I have a possible solution...
Re: Preventing Domain Spoofing - Problem With A Twist?
Attempted to send via email. Please let me know if you need anything else!
- shawniverson
- Posts: 3649
- Joined: 13 Jan 2014 23:30
- Location: Indianapolis, Indiana USA
- Contact:
Re: Preventing Domain Spoofing - Problem With A Twist?
Can you send a PM, sorry, my spam trap is just a spam trap...
Re: Preventing Domain Spoofing - Problem With A Twist?
Sent. Thank you again for your assistance!
- shawniverson
- Posts: 3649
- Joined: 13 Jan 2014 23:30
- Location: Indianapolis, Indiana USA
- Contact:
Re: Preventing Domain Spoofing - Problem With A Twist?
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...
Since you already trust these emails from Google groups, why not perform a postfix header check to bypass everything...
/etc/header_checks
Code: Select all
/^Received:/ HOLD
Code: Select all
/^Return-Path: students*@penncommercial\.edu/ IGNORE
/^Received:/ HOLD
Re: Preventing Domain Spoofing - Problem With A Twist?
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!
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:
Code: Select all
/etc/postfix/header_checks
- shawniverson
- Posts: 3649
- Joined: 13 Jan 2014 23:30
- Location: Indianapolis, Indiana USA
- Contact:
Re: Preventing Domain Spoofing - Problem With A Twist?
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
I have a few more ideas, such as using DKIM and DMARC instead of using smtpd_restriction_classes
Re: Preventing Domain Spoofing - Problem With A Twist?
has dmarc been implemented in the current EFA version or is it somewhere on the roadmap?
Re: Preventing Domain Spoofing - Problem With A Twist?
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...
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...
Re: Preventing Domain Spoofing - Problem With A Twist?
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).
Re: Preventing Domain Spoofing - Problem With A Twist?
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
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
Re: Preventing Domain Spoofing - Problem With A Twist?
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.
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.
- shawniverson
- Posts: 3649
- Joined: 13 Jan 2014 23:30
- Location: Indianapolis, Indiana USA
- Contact:
Re: Preventing Domain Spoofing - Problem With A Twist?
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.
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.