Rahul Sundaram wrote: > Ashley M. Kirchner wrote: >> Manuel Arostegui Ramirez wrote: >>> In this case, I would choose to drop packets since they're not going >>> to stop, it's better to do not increase the packets on your interface. >>> >> That's kinda what I thought too, however as far as the sending >> machine is concerned, because it didn't get anything back, it could >> potentially see it as a successful delivery and thus continue to >> deliver more and more crap. On the other hand, if it does get some >> kind of reset... >> >> I don't know. I certainly don't want to increase my traffic, but >> I'd also don't want to give them any reason to believe that they >> reached me and then increase the amount of crap they're sending. > > By rejecting packets, you would be explicitly confirming that you are a > active connection instead of being a blackhole which like any spam you > confirm can increase traffic. As you can see, this can play out both ways. Is that really true? When it comes to dropping packets, every packet is dropped. That means that the initial sync packet that gets the handshake going will be dropped. Thus, the receiving side will not send sync-ack and a connection will never be established. This is also true on the reject side...but in the case of a drop the tcp/ip layer will wait for a timeout on the sending side slowing them down a bit. In both cases the sending application would have to care about these things. If it is email/smtp we are talking about...most spamming SW doesn't seem to care and will retry. In both cases, the message they would be trying to send out would remain in the queue. This is the hint/key to the application deciding if the other end has gotten the message/email. (Remember, we are operating on 2 levels in the stack here.) The act of dropping packets is generally setup as application agnostic. So, if you are going to drop packets from a given source you will be doing it on all ports.
