>> An "anonymous" proxy, configured specifically to hide the original poster No, all proxies are per definition anonymous unless they specifically add the header X-Forwaded-For. Otherwise, the IP becomes “automatically” hidden, if it passes communication unmodified.
That’s why they have become responsible in many cases. People who don’t understand proxies, just set up one, without configuring it properly, and then it starts forwarding traffic anonymously without adding any identification headers. >> Like the telecom operator job is to pass any traffic and not to block >> anything. It’s a entirely different thing, when traffic is passed at a lower layer than layer 7. When you pass traffic at a lower layer than layer 7, then you are just a mere conduit and the “ISP” exception of responsibility apply. Same applies if you forward traffic internally in a organization, as you are just passing the ethernet packets to its final destination. When you pass traffic on layer 7, you are the de facto recipient of the traffic, and when you then “resend” that received traffic somewhere else than its actually destined, you become responsible. That’s why a reverse proxy operator becomes responsibility for content he “host”, even if that is just forwarded requests to a third-party. Think like this: A mail is destined from sen...@sender.com to forwardacco...@forwardoperator.org forwardacco...@forwardoperator.org then forwards the email to someu...@anotheraccount.com When the first mail is sent, then forwardoperator.org is the defacto recipient of the message. They receive the message. But due to a configuration in their server, that message is now sent (as a new message) to someu...@anotheraccount.com Do you understand why the forward operator (and the proxy operator) receives responsibility now? So its nothing wrong that people who configure a email forward, becomes responsible for the messages they forward. It is as it should be. If you want to do forwarding on a lower level than layer 7, then you simply "aim" the domain's MX records to the final SMTP, and then configure that SMTP to accept mails for another domain, and LOCALLY forward that email into a specific account. That may require a paid account at some email operators. The local forward will ensure any validations doesn't fail, because then its already inside that mail operator's file system, and thus all signatures and similar are already verified. Best regards, Sebastian Nielsen _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
