Great video! The description of the SPF qualifiers on the "all" mechanism isn't quite right though. Your description is a common misconception I encounter on security and admin forums frequently. The difference in handling of ~all and -all failures is entirely a matter of local policy on the side of the receiver. Senders should strive to get their records to -all but the difference in how imposter mail will be treated isn't as stark as one may think. The softfail description is somewhat correct in that the RFC specifies the receiver "SHOULD NOT" reject (note it doesn't say "MUST NOT".) However, accepted is not the same as delivered and the message may still be quarantined or otherwise prevented from ultimately ending up in the recipient's mailbox. The RFC on fail (-all) is almost the same but says >>>if>chooses
@@13Cubed just to reiterate: Your video is great. The content is accurate, useful, and easy to follow. Email security is just my entire job and before that I was basically a postmaster so I can depressingly quote all of the relevant RFCs from memory haha :D I think the misconception about how -all and ~all are handled is because in an ideal world the way you described it would be true. In practice though so many legitimate messages fail SPF for a myriad of reasons so filter vendors err on the side of accept but be suspicious unless there's a DMARC record with p=reject. Even then some still accept but quarantine (looking at you Office 365.)
I've been doing some form of email forensics for years, and this is one of the best explanations that I've seen. Great job. I'd welcome much more of this, as well as Mac, Linux and database forensics. Cheers.
Watching this video led me to subscribe to your channel. Thanks for sharing this and keep up the good work.
4 года назад
Again, great video Can you explain how reconnaissance email (not email reconnaissance) the one some APTs use to put an url to verify if the email exists or not without clicking the link? thank you
Hidden tracking pixels and things of that nature are pretty common and can show whether or not someone opened a message without clicking a link. Is that what you’re referring to?
Just send an email from one account to another and look at some of the header fields we've covered here. That's by far the easiest way to become familiar with how to read and interpret the data.
Hey, Thanks for the great video. Lot of cool and needed information. I had a quick question though. How does the MX record and SPF authorised sender differ? I mean can they both be the same too?
Using your mail client, view the mail headers. Then, just copy/paste those headers into Sublime Text, and choose the "Email Header" plugin in the bottom right.
@@13Cubed This information was helpful in understanding but I am still unable to decipher the original sender location of an email from a gmail account. I have emails both sent and received, and determining if the sender is in my state or not would really help me in knowing who is behind the account. Can you help?
MSG files are usually associated with Microsoft Outlook, and aren’t going to be readable in plain text. You’ll need to view the headers within that application and copy and paste them into a separate file for analysis (or otherwise convert the MSG to EML via a third-party application).
