Nathanael Hoyle a écrit :
>
> The IP is a network boundary address. i.e., if it were a class C
> network (/24). the address would be x.x.x.0, rather than 1-254 or
> broadcast (255). Because this IP refers to the *network* rather than a
> host therein, it cannot actually be assigned to a host. This means I
> both avoid wasting an otherwise usable IP, and have no worries that
> something might ever be assigned that IP which would interact in an
> undersired manner with mail delivery attempts. In my particular case
> (which you can find out from the MX records anyhow):
>
> MX 10 nosoupforyou.speedexpress.net
> MX 100 mail.speedexpress.net
>
> nosoupforyou.speedexpress.net A 66.142.28.32
> mail.speedexpress.net A 66.142.28.50
>
> The 66.142.28.32 address is the network boundary for 66.142.28.32/28
> (255.255.255.240 subnet, with .33 as the first usable IP).
>
>
>> the advantage I see is that the connect
>>
>>
>>>attempt will fail notably faster than it would if it had to time out,
>>>which reduces the burden on legitimate hosts, but is still just as
>>>undeliverable, keeping the desired effect. I will post with further
>>>results as I have the opportunity to observe them.
>>>
>>
>
>

The remote system has no idea how your network is subnetted. so the
failure will mostly be caused by a routing error (no route to host)
generated in your network. A tcp rst (generated by an existing host)
would be as fast. I think the advantage is in resource usage (no need to
go through an ip filter or a tcp stack) in addition to what you said
above (no need to use a real host's IP).