Re: DNSBL and IPv6

On 2012-10-20 07:25:04 -0700, Bart Schaefer wrote:
> On Oct 20,  9:30am, Peter J. Holzer wrote:
> }
> } Is there a reason why a legitimate MTA (talking to MXs, not submission
> } servers) would want to hop around in its net?
> 
> A legitimate MTA could still be running in a dynamically-assigned space.
> In this case it might hop all over the space but probably wouldn't hop
> very frequently.

By "dynamically-assigned space" do you mean a dynamically assigned
address within a /64 (either by DHCP or by privacy extensions)? If so, I
already mentioned that and yes, I think it doesn't change fast enough to
make greylisting infeasible (but frequently enough to make it annoying).

If you mean that an ISP is assigning a different /64 to the same
customer periodically (some privacy evangelists are demanding that this
should be the default), then this would probably be done even less
frequently, and this would most likely be treated the same as
dynamically assigned space today (i.e. very likely to be a zombie, not a
legitimate MTA).


> A single MTA host might have multiple NICs each with its own IP, and not
> always choose the same interface for the same MX on retry.  Here it might
> hop quite a lot, but among a limited number of choices.

An IP stack might also choose IP addresses at random or in a round robin
fashion if the interface has several. That could be a problem.

	hp

-- 
   _  | Peter J. Holzer    | Der eigene Verstand bleibt gefühlt messer-
|_|_) | Sysadmin WSR       | scharf. Aber die restliche Welt blickt's
| |   | [email protected]         | immer weniger.
__/   | http://www.hjp.at/ |   -- Matthias Kohrs in desd

_______________________________________________
Asrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/asrg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIVAwUBUIRrAvIOSFES/ihdAQKwjBAAjdDwYJDK7Idz9QYT0FtqkCR9i7zWQu08
D2D86AkTWFZGg/s55y5GYxBcW5I82c2SbuLtpEffQgy7/zBd3KNp9PmuoU51vyVa
AUQi0fE7Xo+KEbYPtwG8Oad7vv3TACgTO0z6WHtUlTl/G6U+ITtbzHmOyDfLUdgc
EhDhocDCKj8Nl+A0zfdOy77qyonV0WrERIulGaNB30j9zNFLoRfbi1lzK9KemH3I
V+IRyEQ1/TdWvsk7nnIrHNVHc5tJYe2Gy2OKa3/h7n97m/QRwHY7FwaMYrt6hkt9
L0q9WFKYeibHLbRzWmsJqJHE7WmpAJCR7ckEQVQY/7LQ6GFmijjYdExjawkidByF
YevipD/Z7tcpMBcUUXda4ax7UVN+IyUzuXEt1Zs5r1WEnN4dvobmomkd0WBpQzyd
Zg2mW08uhQFnUzigpiFkSZ6mj92DIWSdGo9mtzuLkz6oDfxODFFRoNu3BT8a1HUL
79H99XP9iNPwr5L/RCaf/7bi3VheLqBIjYlcfN4wv93S4EksnPDY8mxBvq7VeMmW
HkaAC6fMa46Jg7Kq1O+lZgUuAoScWgdOe80myX78lttJ/Zwh41hBKj6aNoDbg/Ek
oQzl7QkP/ewSZ7/Dga79S5vAyXXogtml8oaT2dVxeZ30lA1/SWo5v4zxOeAVJ/n/
ta3ddWa/3NI=
=iEWw
-----END PGP SIGNATURE-----