I have a large number of banned IPV6 addresses from outbound protection outlook.com. Are those susceptible to prevent POP3 fetches if some incoming messages passed through the banned IPs?
on
IP blocking in Stalwart works at the connection level: an entry in BlockedIp only rejects a new incoming connection from that source address, it does not inspect the Received: header chain of a message to see what relays it passed through. So a message that transited through an IP outlook.com’s outbound protection has since banned will not be treated any differently once it is already stored in a mailbox, and POP3 retrieval of that message is unaffected by that history.
The only way POP3 (or IMAP/JMAP/SMTP) access would be blocked is if the IP address actually connecting to your Stalwart server (e.g. the client fetching via POP3, or a relay delivering mail) is itself in the BlockedIp list or has been auto-banned for abusive behavior. Message-content or header-based IP reputation from a third party like outlook.com’s own outbound blocklist has no bearing on Stalwart’s own blocking logic.
Reference: General | Stalwart and Auto-banning | Stalwart
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
No, those entries cannot affect retrieval. The blocked list is consulted in three places only: when accepting an inbound TCP connection, on inbound HTTP, and inside the spam filter. Nothing on the POP3 or IMAP path looks at it, so messages already in the store are served regardless. The spam filter does match IPs found in Received headers against the list and tag them IP_BLOCKED, but that tag has no score in the default list, so it adds nothing to the total.
The accumulation is should be dealt with for a different reason: those are Microsoft’s outbound hosts, so the next time one of them connects the connection gets dropped and you lose legitimate mail from Exchange Online senders. Have a look at the reason on a few of the entries. Relay or RCPT TO probing (abuseBanRate, default 35 a day) is the usual trigger for large senders that try recipients that do not exist; loitering (loiterBanRate, default 150 a day) is the next most likely.
Two things to change: add Microsoft’s published outbound ranges under Security > Allowed IPs, since the allowlist overrides the blocklist and also stops them being re-banned, and set abuseBanPeriod and loiterBanPeriod, because with no period set the bans never expire, which is why they pile up. See Auto-banning | Stalwart.