On 12/04/2015 12:10 PM, Steve Atkins wrote:
On Dec 4, 2015, at 9:06 AM, Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
The CBL docs say it shouldn't be used for blocking logins, but it may be useful
to instantly block IPs which are on the CBL and also make a failed attempt to
login, rather than giving them a few attempts as we normally do. But, given
that our software is used by businesses for themselves, it may be OK to let
them just use the CBL(XBL) outright to block logins, as they can easily change
it if they need to, unlike if it's a huge MSP.
It'd be an additional data source to consider, for sure. But pay close
attention to Chris's comments about what the CBL/XBL lists and the behaviour to
expect from those nodes, and be very aware of corporate farms of windows boxes
behind a single NAT IP.
(I think we're drifting quite a long way from SMTP, let alone where this thread
started, though :) ).
Heh, yah. Which I've been replying only to ietf-smtp.
Corporate NAT farms tend not to be as big an issue as you may think,
because such things tend to use mail infrastructures of their own,
isolated from the NAT, and, having B2B access outside of that (including
unrestrained visitors SMTP'ing to random places) tends to be frowned
upon. We simply did not permit outbound port 25 from anything but the
mail servers even tho we didn't NAT.
Section 7 of the CBL Terms and Conditions gives him an out, his mileage
(direct usage or in combination with other information) will vary
depending on his environment.
Corporate/organizational (rather than provider) may do quite well
without running afoul of the FP caveats. He can but experiment, measure
and decide for himself.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp