On 12/8/20 2:10 AM, Thomas Walter via mailop wrote:
So in that case you are against servers supporting SRS since it breaks your idea of how email should work?
As a sender? Yes.
As an email server operator that supports forwarding? No. - Yes, I have SRS configured and functional. Though I only apply it to outgoing messages that the SMTP from is not a domain that the servers are authoritative for.
Aside: I think someone questioned the venerable .forward functionality in relation to SRS. -- Perhaps I misunderstood the comment. -- Yes .forward (or alias local address to remote address works perfectly fine with SRS.
This discussion really reminds me why I never liked this broken by design concept and never will. Yet I am forced to support it, because the big fishes decided otherwise.
We obviously disagree.
Can someone point me to statistics about how effective SPF is compared to other antispam measures?
I stated the disagreement above because "antispam" can mean a lot of different things to different people. I say this because some people consider spoofed email to be spam while others consider spoofed email to be something other than spam. This is germane because SPF can be one of these and not the other.
SPF can be quite effective against spoofing actual email addresses from companies that have a strong hand in how their email works including publishing proper SPF records. -- That particular task is completely independent of filtering out recreational drugs or stock pump and dump spam.
I consider SPF to be one of many tools in the email hygiene toolbox, each used to combat slightly different problems. Collectively, they can do quite a good job cleaning email flow.
Spammers using phished/hacked accounts don't care. Spammers with their own domains just add SPF records and can easily include (hacked) third party systems?
Which is why SPF is not a good anti-spam technique.I consider SPF to be an acceptable way to know if an email came from an authorized source or not. Specifically in a federated like manner.
Phishers just use mail0p.org with correct SPF records to foil targets or just use 'From: "Example <i...@example.com>" <hac...@example.org>' since modern MUAs decided it's a good idea to not show mail addresses anymore...
That tells me that SPF has been effective to protect mailop.org. As such, I can be more confident in trusting email from mailop.org than i can in trusting mail0p.org.
Different tools protect against different things.Would you argue that keeping matches out of kids reach is useless when they can find a hammer and crush their thumb?
Perhaps I should just start looking into botany.
I'm confident that there are things in botany that will annoy you too. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
