Vyachelsav followed up,
Z> Ok. The X-Loop: header is intended for preventing replying the autoresponder
Z> script to itself and nothing more, right?
Exactly.
Z> One more question. Should I check just X-Loop: header occurance or its
Z> specific content too? For example, X-Loop:
ping(_dot_)robot(_at_)my(_dot_)domain
In this particular case, I think the ping responder should reject anything
with an X-Loop: header, regardless of content. The presence of an X-Loop:
header indicates that the message was generated or distributed by a bot
rather than being addressed and typed individually by human fingers. There
are cases where the content does matter and a recipe should reject only its
own X-Loop:, but I feel that this is not that kind.
I had said,
T> As I understand your post, Vyacheslav, that part works properly. Something
T> else is the problem: you write to the ping responder, it sends you the ping
T> data, and for some reason you want to reply to its message. When you start
T> to compose that reply, your MUA does not copy the X-Loop: header from the
T> ping response message. Well, no, it wouldn't.
Z> Why it wouldn't? Because it is a custom-added header?
Because MUA's just generally don't copy headers over, except for the subject.
Z> Not quite right. The matter is I don't want to be bombed by so-called
Z> hackers that will send a bunch of ping requests in short amount of time.
Now that's a different story. At first you asked how to avoid sending ping
responses when people send replies to earlier ping responses.
Z> But I've already dealt with this problem. Pinging is a password-protected
Z> and I am using '${FORMAIL} -D 16384 ${HOME}/help.cache' to analyze whether
Z> to send or not a ping request's help file.
Close; you need -rD there rather than -D. -D checks Message-ID's for dupli-
cates while -rD checks for duplicate senders. (And you don't need the braces
around the variables' names.) The one drawback is that such a cache is of a
fixed maximum text size, and depending on total ping request volume names may
scroll off too soon or linger too long, so you might want to set up a time-
based system instead. Time-based caches have been discussed here before, but
I don't recall any consensus on the best way to set them up.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail