On 17/12/2022 19:37, Wietse Venema wrote:
EML:
I've written a milter to replace a hand-coded SMTP relay. This works,
but I'm having a problem handling bounces.
The 'relay' actually handles private mailing lists which must be
anonymised (for minors). A user sends a mail to 'virtual' addresses, and
the relay does a database lookup, and forwards the incoming mail on to
the real addresses of the recipients. 'Virtual' in this sense means that
all users get a made-up address ('[email protected]'), so the
relay just converts between real and made-up private addresses/./
In the Postfix equivalent, the new milter doesn't work without this
entry in virtual_alias:
@private.example.com? my-email-address
Where 'my-email-address' is a local address (which isn't required or
monitored). So, Postfix first checks the incoming address in
virtual_alias; if there is a match, the milter is called. The milter
then anonymises and sends on the mail to the real recipient addresses.
Note that general name translation is /not/ handled in virtual_alias,
because there are hundreds of names, and they're constantly changing,
and this is all tied up with a membership database that does lots of
other things.
This all works, but there's a problem with bounces. If a bounce is
returned with RCPT TO set to <>, postfix/bounce takes over, looks up
virtual_alias, and does local delivery to 'my-email-address', /without
calling the milter/. This is no good, since I don't want to read all the
You can control bounce inspection with internal_mail_filter_classes
(you would need to enable non_smtpd_milters for that), but locally
generated bounces is not recommended because that can result in an
email explosion (one message geneates a bounce which generates a
bounce which geneates a bounce and so on).
For a good recommendation we need to know NOT what solution is (i.e.
NOT the frankenstein solution that you are trying to implement).
but the problem you are trying to solve (something with sending
email with anonymized senders).
Wietse
Hi Wietse - I didn't want to bore you with the problem, but since you
asked... :)
Imagine a kids sports club which needs a mailing list. Some adults
(coaches, for example) are authorised to mail individual kids, or groups
of them. No-one is authorised to use real ('physical') email addresses;
you're not allowed to set up direct communication. Everything must be
done blindly. I know, this might sound stupid, but it's a real
requirement in these clubs.
My old SMTP relay handled this by giving everyone 'virtual' addresses in
a subdomain. The (physical) MAIL FROM address was checked to confirm
that it was authorised to contact all (virtual) recipients. The MAIL
FROM was deleted, and changed to the sender's virtual address. All RCPT
TO addresses were changed from virtual to physical. The final message
leaked no physical addresses, and was then forwarded on to the final
recipients by setting up an SMTP connection to an MTA.
This works well, but has some flaws. First, it doesn't do SPF or DKIM
checking on incoming mails; second, it doesn't provide 'normal' mail
server functionality, without the anonymisation. The answer was to
rewrite the code as a milter, and plug it into Postfix.
Note that the current milter code does an SMFIS_DISCARD when it has
received the complete message, and then sends it on 'manually' by
calling postfix/sendmail on the new message. This means that
'non_smtpd_milters' is a problem, because the new locally-submitted
message is passed back to the milter, but I can fix the milter to ignore
the new message.
This is all good, except for the one problem with bounces. If a bounce
comes back to Postfix it's handled by postfix/bounce and the milter
doesn't get a chance to find out who the bounce should really go to:
1 - (MAIL FROM [email protected], RCPT TO [email protected]) -->
2 - Milter at example.com -->
3 - (MAIL FROM [email protected], RCPT TO [email protected]) ->
4 - bounced by outlook.com -->
5 - Postfix at example.com swallows the bounce, and doesn't return it to
[email protected]
However, postfix/bounce *is* useful for 'ordinary' emails, where a user
has local delivery on this server.
Sorry it's so complicated!
