Point Postfix at a Mail Relay, Not the Web Proxy
Choose an SMTP relay for Postfix and distinguish it from an HTTP CONNECT route.
relayhost = proxy.example.net:3128 looks plausible until the two ends begin talking. Postfix expects an SMTP peer. A web proxy on 3128 expects an HTTP proxy request. Neither gets the conversation it was waiting for.
If the network provides an approved mail relay, configure that SMTP service instead. A typical shape is:
relayhost = [smtp-relay.example.net]:587The hostname and port are examples. Brackets suppress MX lookup for that relay name. They do not add HTTP CONNECT, TLS or authentication. Configure the relay's required submission, SASL and TLS settings separately.
The two accounts can be different as well. A password accepted by the web proxy is not automatically a mail-submission credential, and the relay can still reject a sender after accepting the connection.
What if the only approved path is a tunnel?
An HTTP proxy can carry SMTP through CONNECT when it permits the destination and port. That does not make an arbitrary SMTP client generate CONNECT. A tool such as curl has an explicit proxy-tunnel option; setting Postfix's relayhost is a different interface.
A fixed SSH forward or a purpose-built local transport adapter can expose one approved SMTP service as a local TCP endpoint. In that design, Postfix talks SMTP to the endpoint, and the adapter supplies the other transport. Keep it restricted and preserve the intended mail server's TLS identity: changing the connection address to loopback can affect name-based certificate policy.
Prefer the mail relay when that is the service the network operator supplies. It gives queueing, sender policy and delivery errors an SMTP-aware home. A web proxy setting alone supplies none of those mail functions.