Another suggestion is to put all outgoing target adresses in whitelist. It should be easy to insert a rule in the submission server, so all outgoing RCPT TO adresses gets auto added to whitelist.
In this way, replies to email never gets delayed - AND if you get problem with 2FA codes that gets delayed, just send a garbage message to the noreply adress that sends the 2FA codes. If this mechanism is abused (read: spammers registering local accounts and then sending email to their own sender adresses to get them whitelisted in the system), a way could be to detect if some account's "auto add" contributed to many SPAM rejects which passed greylisting. (for example, if you run a public mailservice like hotmail or similiar). How: just record which local account "auto add"ed a email to whitelist, and for each local account, keep a tally for "spam whitelist source". For each email that passes greylist BECAUSE of auto add outgoing, *AND* this mail is classified as definitely spam, or someone reports a email as spam. Then just add +1 to this counter. If this tally becomes too high, ban the account for "Sending messages to spam senders and/or replying to spam". Then you can also erase all whitelist entries that can be sourced from that particular account. -----Ursprungligt meddelande----- Från: Vsevolod Stakhov via mailop <[email protected]> Skickat: den 27 november 2025 11:37 Till: [email protected] Ämne: Re: [mailop] Greylisting effectiveness vs. drawbacks. On 27/11/2025 00:01, Kyrian (List) via mailop wrote: > Folks, > > Time for a major change to spam handling for me. Possibly overdue. > > What's the consensus? In times where 2 factor authentication emails are > frequently completely pointless trying to go through greylisting where > they are delayed beyond their timeouts. But where spammers obviously > still persist. Is it still worth trying to greylist, or rely on other > methods instead? Is it the case where SMTP-time spam/virus scanning is a > necessity and greylisting should be removed? How do other folks on the > list balance out this conflict in their systems? > > K. I always suggest to do selective greylisting as an alternative to unconditional greylisting and no greylisting at all. In general, you do not greylist apparent HAM (e.g. mails from your trusted senders or dmarc/dkim whitelists) but you do greylist suspicious messages. Why do it - because on the second attempt a malicious content (e.g. urls, IP addresses or even content hashes) could strike spamtraps in the world and that message will be properly classified not as suspicious but rejected/quarantined as SPAM. That's the default way of greylisting in Rspamd, and the only drawback is that you'd have to read message till EOD to do that. On the other hand, Rspamd won't do expensive checks if greylisting threshold is reached, and it will use content hashes to allow greylisting to be passed if a message is being re-sent from a completely different IP range (that was a known issue when interoperating with Gmail back in past). For sure, even with this approach there could be some troubles with certain 2FA messages, but it's still possible to do some clever exceptions for them (by domains, by IP ranges or even by content that is typical for 2FA messages). _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
