On 8/31/23 8:02 PM, Bron Gondwana wrote:
The classic case was that spam about V*gra was very common, but blocking that word in every anti-spam filter would create something that was really not fit for purpose for Pfizer to use for their email system. The sender and recipient really make a difference about what is spam - and as the sender you don't know who the end recipient is, because there are plenty of recipients.

I've seen -- what I consider to be -- too many systems -- read more than zero -- that apply some amount of spam filtering to inbound message and no spam filtering on outbound messages.

I've also seen many of these systems wonder why they ended up black listed when an account was compromised and someone was sending spam through said system.

I feel like there should be basic spam filtering on outbound messages. Even if it's as simple as logistical checks; making sure the from makes sense, probably running the message through something like a default configuration of SpamAssassin (without Bayes), and probably through something like ClamAV. Just basic sanity checking on messages.

Dare I say, I'd add SPF between the MSA and MTA.

Things to prevent blatant spam / viruses much closer to the -- likely to be authenticated -- sender.

I'll say it this way, if there's a 90% chance that your inbound system would block it, then why should your outbound system send it?

Fact: recipient spam filter has more information than sender spam filter
Result: recipient spam filter can be more restrictive without causing excess damage.

Yes, there is different data.

But there is still data on the sending side that can be used to perform basic checks.

There's no hypocrisy in recognising the asymmetry, and designing with that in mind.

I still think that it's hypocritical to have zero spam filtering on outbound email while having any spam filtering on inbound email.



--
Grant. . . .
unix || die

_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Reply via email to