Supposition
The SPF record for a domain using Outlook Online services typically involves the include:spf.protection.outlook.com mechanism, which in turn cascades into a plethora of IP addresses that are presumably used by Microsoft's distributed hosting.
Presumably this means that if any accounts using these services elsewhere in the world are compromised, they can send out SPAM or similar message content using a forged sender address of any legitimate Outlook Online domain, and still pass SPF ?
Question
Given the broad uptake of Outlook Online / Office365, this seems to be a rather large IP range that can compromise SPF. Is there any way to limit which portions of the IP address ranges a domain can use to send from via Outlook Online, and therefore limit the IP ranges in the SPF record for a domain to something less exposed?
Addendum
Further to #Synchro's helpful answer, I can see that using DKIM and DMARC together will help mitigate the fact that SPF passes too readily, but DKIM isn't a trivial thing to implement, and I would need to cover other mechanisms in my SPF with DKIM too if I make DMARC rigid. My question remains, is there a way to use a narrower set of outgoing hosts under Office365, maybe with a corresponding subset 'include', in the same way that include:spf.protection.outlook.com is a subset of the broader include:outlook.com ?
The short answer: No, you shouldn't want that.
Basically, you're trusting Microsoft to manage IP ranges, as well as verifying domain ownership in such a way that it is not possible for someone in a tenant other than your own to send on your behalf. The large set of subnets is partially to be able to route efficiently and be able to fail-over in case of datacenter failures.
This is not different with other services that can send email on your behalf, for example Oracle Eloqua (9.344 individual IPv4 addresses) and MailChimp (22.528 individual IPv4 addresses) and Google (322.816 individual IPv4 addresses) all tend to include large and many subnets. DMARCIAN has a nice tool to check an SPF and see what it is comprised of.
As mentioned in #Synchro's answer, these subnets are meant to be dynamic / flexible and managed by the owner of the service.
I'm not sure if I understand your addendum and #Synchro's answer, with regard to DMARC. The way DMARC works: it looks for a pass on either SPF or DKIM in order to consider the email authenticated. There's more to it, such as alignment on domains, but that's a bit our of scope for this question. So as a supplement to your SPF, that would only work if you remove Office 365's SPF include entirely and solely rely on DKIM authentication to satisfy DMARC.
Personally, I like the redundancy of having both, because both SPF and DKIM can be broken in certain scenario's, like mailing lists or forwarding rules. Setting up DKIM per domain in Office 365 is actually quite straightforward. All you need to do is create 2 CNAME records per domain and enable it.
Finally, SPF is not the anti-spoofing holy grail and you should look into DMARC for this. SPF is checked on the return-path header, not on the email address that the recipient gets to see. So your domain can easily be spoofed while still passing SPF on the domain that is used in the return-path email address, unless you use a restrictive DMARC policy (and the receiving server actually adheres to the DMARC policy).
Yes, your supposition is correct, however, it's not safe for you to create subsets of their IP ranges as they could change at any time, along with the source IPs used by your messages, i.e. O365's SPF record is dynamic. This is the main reason for using include mechanisms in your SPF, so you don't have to maintain such ranges. Also bear in mind that even O365's large ranges represents a very small proportion of the internet, and an even smaller subset of spoofed message sources.
The right way to do this is to supplement your SPF with DKIM. The combination of SPF and DKIM would get you the results you're after when combined with a strong DMARC policy, because even if someone can get past your SPF, they can't forge your DKIM signatures.
It's possible to get O365 to do DKIM signing for your domain, though it's a rather convoluted process.
Related
One of my websites sends emails from various sources including:
Mailchimp
Mandrill
Mailgun
Amazon SES
From the server itself
We have correctly configured SPF & DKIM settings for all of the sources so we decided to add DMARC too and at the same time we changed ?all to -all.
All of our emails have been going through just fine but we've noticed our Mailchimp emails are "SPF Incapable" and as such don't fully pass.
Most email clients / accounts show that DMARC has passed, however DMARCian & a few email clients throw up DMARC Fail-alignment
For example:
DMARC.io does however say the following:
SPF: SPF is not possible as MailChimp uses their own domain in the bounce address. Their domain authentication verification tool requires including Mailchimp, though. To work-around this without having to include Mailchimp servers, try including only 'ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.8.0/21' in your SPF record.
So, I added those to my SPF however it still shows:
All of the following IP's are all covered by those CIDR notations so I am unable to work out why the SPF is still misaligned for SPF, but it fixes DKIM...
198.2.185.161
198.2.185.245
198.2.141.4
198.2.175.233
198.2.185.245
198.2.142.122
I did find the following on stackoverflow: https://stackoverflow.com/a/50471866/2487602 however that seems to be slightly wrong in advice because the bounce server is nearly always different. They've got hundreds of servers.
My SPF looks like:
v=spf1 +a +mx +ip4:94.237.30.75 +ip4:94.237.30.85 +ip4:94.237.30.86 +ip4:94.237.30.87 +ip4:54.77.177.67 +ip4:34.246.233.211 +ip4:52.18.62.128 +ip4:34.241.119.225 +ip4:205.201.128.0/20 +ip4:198.2.128.0/18 +ip4:148.105.8.0/21 include:servers.mcsv.net include:spf.mandrillapp.com include:mailgun.org include:amazonses.com -all
What have I done wrong/can I improve in order to get the SPF aligned?
On a side note, I assume for the first 4 IP's I could just use: +ip4:94.237.30.75/28 which would include those 4 IP's as well as a 14 or so other IP's which isn't really that risky is it especially when they won't have DKIM and as a result DMARC passing? To make it a little more secure I could just reduce those 4 records down to +ip4:94.237.30.75 +ip4:94.237.30.85/30 which would only include 1 IP that we don't use.
I do also want to send emails via EC2, rather than SES for some emails (potentially to replace Mailgun/SES) however when we send emails from those servers they get sent to spam for not having a reverse DNS.
I assume, the fix for that would be to request a PTR record to be setup by Amazon for the 3x EC2 instances that we use?
I did request one of these before, but I wasn't sure if it is supposed to be pointing to my main website's IP or the IP of the server that it's sending the emails from...
As for SES, even after adding the SPF include and the DKIM record, our SPF record shows "Neutral" rather than "Pass" for example the following is from the "Test Email" feature for SES/EC2
SPF: NEUTRAL with IP 54.240.7.46
So to recap...
How do we make Mailchimp fully pass on SPF so that DMARC is aligned
How do we correctly setup a PTR record for a reverse dns, should the subdomain be pointing to the server it sent the email from or the server of the main domain?
How do I get Amazon SES to throw a SPF Pass, rather than SPF Neutral?
You can't. The answer in the thread you mentioned is correct. Mailchimp will set the bounce address to its own domain. So adding the ranges to your own SPF record will not change anything (SPF is checked on the bounce address, not the header.from address). While you're not authenticating fully redundantly, you're still passing DMARC and it should not impact reputation for your domain (or nobody would be using MailChimp).
Only the owner of the IP address can set the PTR record in DNS. It should point to the name of the server sending the emails, preferably the name in the EHLO/HELO. This thread has the correct answer, I think, though I've never set it up personally.
What is the bounce address domain used in your AmazonSES emails? Did you set up a Custom MAIL FROM address as explained here? A Neutral result is usually returned for an SPF record ending in ?all and not passing on anything that is on the left of it.
Another thing that might be happening (if the SPF Domain is your own domain) is that you're hitting the "characters-per-string limit" for DNS TXT records. If you haven't cut the record up in at least 2 strings, the check might not get executed beyond the Mailchimp include. And with the absence of an all modifier (not evaluated), it defaults to neutral. You can see what your SPF record looks like with any lookup tool, but querying your domain with https://dns.google.com for TXT records should show you (escaped) double quote (") marks for where the string has been cut. As an example you can check this SPF record to see what it looks like: […]ip4:185.211.120.0\"\"/22 ip4:185.250.236.0/22[…]
One last thing to note is that you're close to the DNS lookup limit. It looks like you're at 8 lookups already. Beyond 10 lookups will cause the SPF check to result in a PERMERROR
I need to send 10k mails. What is the maximum limit that outlook(professional account) allows?
A brief search of their TOS does not yield a hard number. They do however state in their Code of Conduct:
a. By agreeing to these Terms, you’re agreeing that, when using the Services, you will follow these rules:
...
iii. Don’t send spam. Spam is unwanted or unsolicited bulk email, postings, contact requests, SMS (text messages), or instant messages.
...
Sending 10k emails in a short time (even a week might be considered "short" in this regard) may very well trigger inbuilt spam detecting (both by microsoft and the e-mail providers of your recipients, even if the emails are not unwanted/unsolicited).
I can only strongly advise you to directly contact a service representative from outlook/microsoft and clear things with them beforehand, to avoid any unpleasant surprises or legal hassles.
I am studying CalDAV protocol.
I have some question for time conflict or overlap for CalDAV.
Let me explain by instance for some scenario.
I made an event PM1 ~ PM6 in calendar. And then I try to made another event PM2~7 in same calendar. It is time conflict or overlap.
How does CalDav server resolve this conflict? Does server make error when second event make?
I did search out RFC 6638. But I could not find solution.
Please help my question.
Thanks for reading.
It is up to the CalDAV client to decide how to behave when overlap is involved.
If the client decides to write an event that overlaps another the server will write the overlapping event.
When scheduling is involved (userA wants to invite userB to a meeting but would like to avoid picking a time slot that is already busy in userB's calendar) the CalDAV client can query the FREEBUSY status for a user (see RFC 4791). There's also availability which allows a CalDAV client to retrieve a user's availability (think business hours).
The functionality Kim is asking for a very common one for business calendaring systems (not have the same person booked twice etc).
I think in the CalDAV world there are two parts to this:
a) First the client is supposed to perform a freebusy query to check
whether a user is available. And then show a conflict warning or
whatever seems appropriate.
This is how many systems, including btw Exchange work. Siri also does this kind of conflict detection (“hey, you already have an event at the time, shall I still create the conflicting one, master?”)
b) But in a reasonable system you actually need to guarantee that
the information isn’t outdated at PUT time. I.e. that no second
client has scheduled the same attendee/resource.
I think in CalDAV you can accomplish that by testing the sync-token or the CTag using an If header on the PUT. I.e. let the PUT only succeed if the whole underlying collection didn’t change. And if it did (the PUT will fail with a conflict), redo the freebusy, then try again.
I don’t think that there is a reliable way to do this in CalDAV cross collections (calendars), that is, if the availability of a resource changed because it got booked in a different calendar, the targeted sync collection won’t usually change its sync tag and the PUT would run through.
The bad thing about CalDAV (w/ scheduling) is that PUTs are not idempotent anymore. Otherwise you could do the PUT, recheck whether it still has no conflicts, and if so drop it after the fact.
I've looked at this question, which didn't have a suitable answer (basically recommends tokenisation). I'm intrigued as to why the fields for delivery address are mandatory as I'm assuming this isn't validated against. The billing address makes sense as this will be the address linked to the card and therefore worth validating. However, the delivery address presumably provides very little.
I can see that it's provided in the response from SagePay in relation to PayPal payments, presumably to check whether this has been altered when getting to PayPal, but as PayPal payments are optional, then if this is the only reason surely it too should be optional?
The reason I ask is that when providing a service rather than a tangible physical product, what should go in this? I'm assuming in most cases this would simply be the same as the billing address, but in the scenario that a 3rd party pays for the service, should the delivery address now be the address of the person receiving the service?
Fraud screening. Sage Pay send all of that stuff to a third party, which then provides a fraud score.
Some of the criteria for that fraud score are based around delivery (known dodgy addresses, business rather than residential, delivery address doesn't match billing etc).
You can just submit billing addresses - you may have to tune your approach towards fraud scores accordingly.
I'm coding a new website that will need users to enter their mobile phone number, the problem I'm facing is that I need to make sure that the user is in fact the owner of (or in this case, has access to) the mobile number.
The solution I've come up with is, upon number submission I send them a SMS with a token and ask the user to enter the token on my website, much like Google Calendar does. However I'm on a short budget and I need to make sure user A doesn't submit 100,000 mobile numbers, if that happens I'll be out of business in no time, since each SMS sent costs me about 0.10 USD.
So far, I've come up with the following solutions:
use a CAPTCHA (keeps some users away and it is still vulnerable to manual registrations)
limit the number of tokens a given IP address request (dynamic IPs, proxies, etc)
limit the number of tokens sent for a given mobile number (a user can request tokens for all the available numbers and when the real user tries to request a legitimate token, his number will be already blocked)
None of these solutions are perfect, how do you suggest I approach this problem?
In a recent project, we were associating SMS numbers with a user account. Each account needed a CAPTCHA and email activation. The user could activate SMS via token, like you are using.
You could rate limit IP addresses (not a total limit). No more than 10 requests from an IP within 5 minutes, or something like that.
And/or you could limit outstanding SMS requests. After an IP address requests a token for SMS, it must be submitted before that IP can request for another SMS number. Or no more than 10 outstanding SMS tokens per IP per day.
Also, like #Alan said, we put a cap on our SMS messages per month.
I would use a combination of CATPCHA and Limit the requests of a Given Mobile Number.
In addition you should be able to specify with your SMS aggregator a preset limit per month. After you reach that limit, service is shutoff. That way if you are a victim of an attack, you will only be liable for a limited amount of money.
Instead of SMS, you can make use of an automated service that calls a phone number speaks out a One Time Password (via Text 2 speech). These services are similar in pricing to SMS, and less likely to get spam abused, as there is more overhead.
Twilio cost $0.03 a minute, or in this case, $0.03 a call.
You could do what Twitter does, which is have the user text you the token (rather than you texting it to them).
This will require you to find a provider that let's you receive texts for free (or close to it), but that might be easier.
Why is SMS costing you a dime? Utilize the EMAIL address that is associated with every SMS system (at least here in the U.S).
http://www.sms411.net/2006/07/how-to-send-email-to-phone.html
If someone tries their best to abuse a system, they will more than likely find a way to do it.
Using a combination of the techniques you've already come up with is likely the best way to thwart most malicious users.
Limit what people can do (no more than 10 requests from 1 ip in 10 minutes, one phone number can only recieve 3 texts a week, captcha before number entry), but more importantly, if people have no control over the content of the message there's no real reason to exploit it.