The problem with encapsulating like that is it basically makes it impossible to 
respond to the original email sender. It destroys functionality that has been 
around since the early stages of email. If we’re going to break email for 
people, then we should at least give them some good reason to break it. 

So what is the tangible win here?

laura 

> On 12 Feb 2024, at 11:15, Sebastian Nielsen via mailop <mailop@mailop.org> 
> wrote:
> 
>>> Many antispam filters will right away classify such an email as spam.
> 
> No, that’s not true, UNLESS the antispam filter resides as a local software 
> in the client's software as a plugin to the email client, which would of 
> course detect the "attached file" even its not technically an attached file.
> 
> Remember that it’s the end user client who renders the encapsulated email as 
> an attachment.
> Technically it is not an attachment, and will not get detected as an 
> attachment in mail filters.
> Its technically an email encapsulated in an outer email.
> NDR also is technically the original email encapsulated in an outer email.
> 
> Technically, an encapsulated email looks like this:
> 
> From: exam...@example.org
> To: exam...@example.com
> Subject: Fwd: Hi!
> Content-Type: message/rfc822
> 
>       From: exam...@example.org
>       To: exam...@example.com
>       Subject: Hi!
>       Content-Type: text/plain
> 
>       Content text.
> 
> Spam filters react on 'Content-Disposition: attachment; filename="test.txt"' 
> and similar things.
> 
>>> Conceptually, it's more like a HTTP proxy server.
> 
> No, because in the proxy case, it’s the "sender" who asks the proxy server to 
> "fetch" something from "receiver"s location. It’s the opposite way, the 
> "sender" trust the proxy, and know that the "content" is genuine if he trust 
> the proxy, thus the proxy bears no responsibility for the content from a 
> location he asked the proxy to fetch content from.
> 
> However, if an end user SENDS something via the proxy, let's say a forum 
> post, the proxy usually bears the responsibility for the content, which we 
> have seen in numerous court cases where a proxy have been used to hide the 
> origin of illegal content, where the proxy owner have knowlingly been a 
> forwarder of such a content (eg, been negligent and refusing to for example 
> block forum posts from his proxy).
> 
> ------
> You could see it more like a reverse proxy.
> 
> A reverse proxy is a proxy, which is configured to show a domain (let's say 
> example.org) and show another web page (let's say letsencrypt.org) inside. 
> The reverse proxy of course bears ALL responsibility for the content its 
> "hosting" via its proxy function, meaning if letsencrypt.org would 
> accidentially host something illegal, the proxy owner will take the blow for 
> the content visible via "his website".
> 
> Best regards, Sebastian Nielsen
> 
> _______________________________________________
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

-- 
The Delivery Expert

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Delivery hints and commentary: http://wordtothewise.com/blog    






_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Reply via email to