First i am not looking to run a farm for Mail proxies, with various combination of functionality. One should suffice....
The mail proxy / firewall required functionality is mostly done by the Proxmox Mail Gateway
Scan / Sanitize all incoming mail against SPAM, Virus etc.
Scan wild outgoing mail against SPAM ViRUS, etc.
Observation:
1) On a maillist SPAM filter does filter lots of stuff (although some are still acceptable) the acceptable mail often does get blocked when forwarded to f.e. gmail. Perfectly acceptable mail (Score = between 0-1) often is blocked on output with score between 3-5 (same content, different address, sent through port 26).
Address SRS transformed, and destination is any public address (otherwise there is a problem with mail originating from gmail, returning to some gmail).
2) SRS needs to be an (standard) option .. SRS or ARC us something that is needed in the current mail world. ARC is also on the rise, with Microsoft starting to require it, GMAIL as well. AFAICT, Google intends to mark all valid DKIM signed messages that are forwarded with another VALID DKIM inside as "unsigned".
3) some mail providers require some form of authentication.
Remedies:
1) supply a method for sending mail WITHOUT blocking, and still have SPF, DKIM signing etc. done. (f.e. port 27 = sending without SPAM/VIRUS check and does handle SRS,ARC, DKIM signing etc.)
2) add SRS to the proxy service. for OUTGOING public mail. with a set of domain names.... (when DKIM, signing is done). This might need better support of "pipelines/channels"
3) allow for authentication on transports.
4) have a better distinction of pipelines ... Like a firewall... OUTSIDE, INSIDE, TRUSTED INSIDE.
OUTSIDE -> INSIDE - handle AV, Anti-SPAM, HELO/EHLO validation, SPF, ARC/DKIM validation, SRS NDC processing
OUTSIDE -> TRUSTED INSIDE - the same, possibly with stricter limits on AV, Anti-SPAM
INSIDE -> TRUSTED INSIDE - handle AV, etc. like OUTSIDE -> TRUSTED INSIDE
INSIDE -> OUTSIDE - handle AV, Anti-Spam, DKIM Signing, SRS/ARC generation,
TRUSTED INSIDE -> INSIDE pass.
TRUSTED INSIDE -> OUTSIDE DKIM Signing, SRS/ARC generation
Possibly SRS / DKIM generation needs to be a part of the transport specification
Nice to have to allow per transport settings for concurrency, quota ( number of mails / hour), limit on number of recipients / mail.
The mail proxy / firewall required functionality is mostly done by the Proxmox Mail Gateway
Scan / Sanitize all incoming mail against SPAM, Virus etc.
Scan wild outgoing mail against SPAM ViRUS, etc.
Observation:
1) On a maillist SPAM filter does filter lots of stuff (although some are still acceptable) the acceptable mail often does get blocked when forwarded to f.e. gmail. Perfectly acceptable mail (Score = between 0-1) often is blocked on output with score between 3-5 (same content, different address, sent through port 26).
Address SRS transformed, and destination is any public address (otherwise there is a problem with mail originating from gmail, returning to some gmail).
2) SRS needs to be an (standard) option .. SRS or ARC us something that is needed in the current mail world. ARC is also on the rise, with Microsoft starting to require it, GMAIL as well. AFAICT, Google intends to mark all valid DKIM signed messages that are forwarded with another VALID DKIM inside as "unsigned".
3) some mail providers require some form of authentication.
Remedies:
1) supply a method for sending mail WITHOUT blocking, and still have SPF, DKIM signing etc. done. (f.e. port 27 = sending without SPAM/VIRUS check and does handle SRS,ARC, DKIM signing etc.)
2) add SRS to the proxy service. for OUTGOING public mail. with a set of domain names.... (when DKIM, signing is done). This might need better support of "pipelines/channels"
3) allow for authentication on transports.
4) have a better distinction of pipelines ... Like a firewall... OUTSIDE, INSIDE, TRUSTED INSIDE.
OUTSIDE -> INSIDE - handle AV, Anti-SPAM, HELO/EHLO validation, SPF, ARC/DKIM validation, SRS NDC processing
OUTSIDE -> TRUSTED INSIDE - the same, possibly with stricter limits on AV, Anti-SPAM
INSIDE -> TRUSTED INSIDE - handle AV, etc. like OUTSIDE -> TRUSTED INSIDE
INSIDE -> OUTSIDE - handle AV, Anti-Spam, DKIM Signing, SRS/ARC generation,
TRUSTED INSIDE -> INSIDE pass.
TRUSTED INSIDE -> OUTSIDE DKIM Signing, SRS/ARC generation
Possibly SRS / DKIM generation needs to be a part of the transport specification
Nice to have to allow per transport settings for concurrency, quota ( number of mails / hour), limit on number of recipients / mail.
