Ronald F. Guilmette <[EMAIL PROTECTED]> wrote:
> Speaking of ``probes'', I have just been dealing with a problem on my end
> that is rather annoying [..]
> The problem is that 9apparently) Listserv cane be told (by the list owner)
> to perform some sort of a ``probe'' on a given address which may be bad,
> and it will then go and try to do that.
>
> Now get this... if the probe FAILS... which is to say if the address is
> in fact bad... then it appears that Listserv then tries to send a ``probe
> failed'' message TO THE ADDRESS THAT JUST FAILED!
>
> No, I'm not making this up.
>
> That doesn't bother me so much as the WAY in which these idiotic ``probe
> failed'' messages are sent... They appear to be sent with a null/empty
> envelope return address, thus making them (in some ways related to spam
> filtering) indistinguishable from ordinary Mailer-Daemon bounces for mail
> which was sent *from* my system to someplace else.
Eric Thomas <[EMAIL PROTECTED]> (the author of Listserv) replied:
> it should be fairly obvious why you want to send a "probe failed"
> message with MAIL FROM:<>, in fact it borders on self-evidence. I'm
> sure someone else on this list will post an explanation if you
> really can't figure it out on your own after making a *genuine*
> attempt (hint: what is the typical criterion for auto-delete on a
> typical LISTSERV list?)
Although I definately do not agree with this practice, it is indeed
obvious why Eric Thomas wants to send his "probe failed" messages with
MAIL FROM:<> - it is because otherwise it's extremely likely that the
"probe failed" message will bounce, and the list-owner doesn't want to
be bothered by the bounce of the "probe failed" message.
Sending a "probe failed" message in the first place is not 'idiotic'
light it might appear at first glace - in fact some kind of "probe
failed" message is a necessecity in any system which does automatic
bounce processing. The reason is that there are broken gateways and
misconfigured MTAs which send a "delivery failed" bounce even if the
message was in fact delivered to the recipient. In this kind of
situation the "probe failed" message is important since it gives a clue
to the subscriber about what is going on.
However I agree with Ron that
a) Sending the "probe failed" message immediately after the probe has
failed is not a terribly good idea; it is advisable to delay it a
couple of hours or a day.
b) Such a "probe failed" message MUST NOT be sent with MAIL FROM:<>
In fact, RFC821 is very clear that e-mail messages are supposed to
have a good reverse-path
: The argument to the MAIL command is a reverse-path, which specifies
: who the mail is from.
and later the exception of bounces is introduced with the words
: prevent loops in error reporting is to specify a null reverse-path
: in the MAIL command of a notification message. When such a
: message is relayed it is permissible to leave the reverse-path
: null.
(Note: By section 5.3.3 of RFC1123 in this case the reverse path MUST
be null).
Note that Listserv's behavious cannot be defended by classifying the
"probe failed" message as a bounce, because then it'd be a bounce of
the bounce of the probe, and hence be illegal by section 5.3.3 of
RFC1123.
Conclusion: Since Listserv violates RFC821 which is a generally
accepted standard and this violation makes life unneccessarily hard
for those who develop anti-spam software, Listserv should be fixed.
Eric also wrote:
> It seems that my signoff request needs to be approved by the list
> owner (?), but consider me gone.
I am surprised to see you leave the list-managers list in reaction
to Ron's criticism. Nobody asks you to waste your time on a flame
war, but when your software creates problems for others, and these
problems can be solved by making your software conform to well-
established internet standards, then it is your responsibility as a
net citizen to fix the software, and _not_ run away from the mailing
list where the issue is discussed.
-- NB.
