[mjl-]

1. no 2fa in the webmail yet. work is currently underway at the ietf for standardizing chained SASL (auth) mechanisms, and passkeys. i want to look at implementing passkeys already for the web interfaces, but there is much more on the todo-list... 2. i as shown by yamrzou, i don't think so. SASL auth really just uses 1 auth mechanism at the moment. i think there is also standardiziation work underway for password+totp sasl authentication. but clients (like thunderbird) would still have to implement it before it's useful. there may be a trick to get 2fa-like authentication now, using both TLS client cert authentication (mox supports this based on public key identification, no other properties of certs) and a IMAP/SMTP-level SASL authentication. 3. no, but this is interesting. what kind of rules would you set? rules to match specific message headers/content that identify a message a phishing and reject it? for when attackers send the same message to many employees? do you need to remove messages from their inboxes after it has been delivered (assuming all employees would get the email at around the same time)? 4. no, but i've considered adding it. it should be very simple to add. and it's much better than mail servers modifying the message content to add messages like that.

[VladVladikoff]

It's good to hear you are working on 2FA that is certainly one of the biggest requests we receive lately for our self hosted email, and has almost pushed me to switch to cloud based services.

With regards to thunderbird and 2FA, it appears that there are some third party solutions, i don't quite understand how they work, looks like they are using SAML or something. https://www.miniorange.com/thunderbird-2fa-mfa-two-factor-au...

To give you an example for the BEC filters we are using, we use the postfix header checks with a negative lookhead regex. For example:

  # /etc/postfix/header_checks 
  # block impersonations
  /^From:\s"?Firstname.*(Lastname)?"?.*?<(?!(.*@domain1\.com|.*@domain2\.com|.*@domain3\.com|personal\.email\.account@gmail\.com)>).*$/ REJECT Sorry the server is busy right now.

I would say that this approach is certainly not ideal, it's hacky and manually maintained. I personally believe that a smart mail server should be aware of what it's users use for [e-mail] combinations and it should either block or soft block (show warning badges in the webmail client) mail which does not follow the pattern of the defined users.

We also use the mime header checks to block some bad attachment types (this is kind of oldschool there are certainly more modern approaches)

  # /etc/postfix/mime_header_checks 
  # block bad attachments
  /^\s*Content-(Disposition|Type).*name\s*=\s*"?([^;]*\.(ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|htm|html|inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ops|pcd|pif|prf|reg|scf|scr\??|sct|shb|shs|sh|shm|swf|vb[esx]?|vxd|wsc|wsf|wsh)\b)(\?=)?"?\s*(;|$)/x REJECT Attachment name "$2" may not end with ".$3"

Re #4 yes, I agree, modifying the actual the mail breaks DKIM, you can really only do this in webmail.