Re: message encryption with SMTP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Jan 4, 2022 at 2:15 AM Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:


On Mon, Jan 3, 2022 at 2:46 PM John Levine <johnl@xxxxxxxxx> wrote:
It appears that Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> said:
>The big benefit of moving to a separate infrastructure in which every
>message is authenticated and subject to access control with a default deny
>posture is we can leave the SMTP anti-spam heuristics behind.

Well, for about 15 minutes until we are reminded the hard way that
"authenticated" is not a synonym for "not spam".  Spammers are if
anything better at DMARC, DKIM, et al., than legit senders.

authenticated and subject to access control with a default deny posture 

The access control is the key. J random grifter cannot send Alice spam BECAUSE SHE HAS NOT AUTHORIZED HIM TO SEND MESSAGES TO HER.

DMARC, DKIM etc cannot provide anything of the sort because authentication is an afterthought and only really authenticates the outbound MTA, not the original sender.


dmarc/dkim/spf all operate at the MTA level.
Or, possibly you could think of these at not operating at the end of the discussion, but in the middle.
 
If Alice authorizes Bob to send her mail every message will be delivered. There are no heuristics involved. No content filtering. This is the key thing for me, I want to have guaranteed delivery for messages sent from my family, certain colleagues, etc etc, SMTP cannot deliver that.


Sure, but email can. An MUA can certainly implement these restrictions.
There's a cost in exposing the relationship data to the MTAs though, which will move the attack targets.
 
And solving spam without content inspection is of course an absolute precondition for use of end-to-end encryption.

Of course, nobody is going to be able to stop spam according to every single person's definition of spam. But I can address 100% of the reasonable definitions:

* Nigerian letters - not unless Alice authorizes the sender
* NFT offers - not unless Alice authorizes the sender
* Political mailings- not unless Alice authorizes the sender
* Mailing lists - not unless Alice actually signed up


you don't need any new technology to do any of the above, you just need your MUA to deny all mail except
that which matches a regex <bob}alce|jane|jim> etc...

again, i'd say there's a lot of tilting at windmills still and not a lot of requirements list, that could be matched against both the current capabilities/misses and placement in the layer hierarchy.

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux