In message <[EMAIL PROTECTED]>, you wrote:
>I did a little looking around and there is not much concrete
>information on the use of that header, but this article
>
>http://mail-index.netbsd.org/netbsd-bugs/1998/02/25/0000.html
>
>Does suggest that it's use is more or less defined by the
>'vacation' program created many many moons ago...
>
>Ron suggested that bulk may cause problems...
>
>Ron - A question... is anything broken?
Yes. TMDA challenges and/or TMDA "confirmation confirmations" will _not_
make it past the spam filter that I am building at the present time, and
that is actually because of _three_ separate a different screw-ups.
(It is hardly possible to have botched automatic responses any more badly
than has been done in TMDA.)
Look at the confirmation confirmation message attached below. There are
three separate problems with this:
1) It uses "Precedence: bulk" instead of "Precedence: junk", thus
flaunting and ignoring the PRE-EXISTING and well-established
conventions used by 80% of the world's other software packages
that automatically generate one-shot automated e-mail responses.
2) It fails to include the Message-ID: of the message that it is a
response to, either in an In-Reply-To: header or in a References:
header.
3) Last and worst, this message was sent using a null envelope sender
address (represented here by "MAILER-DAEMON" which is how my own
local mail server interprets and re-writes null envelope sender
address).
The fact that there are quite a lot of dummies in the world (sadly
including quite a lot of major ISP abuse desks) who have created
brokenware autoresponders that use null envelope sender addresses
doesn't make it right. The original (and still intended) purpose
of the null envelope sender address, for those of you who don't
know, is as a means of returning to the original sender of some
original message an UNDELIVERABLE BOUNCE notification message,
and that is in fact ALL it should ever be used for. There is
neither any need, nor any justification to ever use it in any
other context, and doing so simply hampers both human and automated
attempts to either locate or validate the human or software agent
that is sending the message with the null sender envelope address.
No human and no autoresponder should be using null envelope sender
addresses for any purpose other than UNDELIVERABLE BOUNCE notifi-
cations. (In general, that is already true, but in e-mail, as
with everything else in life, _somebody_ always had to f**k it up
by hastily writing code without bothering to either (a) read the
relevant RFCs or to (b) study actual current, pre-existing, and
established practice.)
Because TMDA automated response messages fail to follow well-established
existing practice, not in one, or tow, but in ALL THREE of the different
ways noted above, those messages, unlike automated response messages from
other and more well crafted software, will NOT make it past either my
filter, or other intelligent junk filters that make some attempt to allow
in legitimate automated response messages.
======================================================================
Return-Path: MAILER-DAEMON
Delivery-Date: Thu Oct 23 12:45:24 2003
Return-Path: <>
Delivered-To: [EMAIL PROTECTED]
Received: from falstaff.isc-net.upenn.edu (FALSTAFF.ISC-NET.UPENN.EDU [128.91.3.
27])
by segfault.monkeys.com (Postfix) with ESMTP id 35DAA41F58
for <[EMAIL PROTECTED]>; Thu, 23 Oct 2003 12:45:24 -0700 (PDT)
Received: from FALSTAFF.ISC-NET.UPENN.EDU (LOCALHOST.UPENN.EDU [127.0.0.1])
by falstaff.isc-net.upenn.edu (8.12.9/8.12.3) with ESMTP id h9NJjNvS0091
14
for <[EMAIL PROTECTED]>; Thu, 23 Oct 2003 15:45:23 -0400 (EDT)
From: [EMAIL PROTECTED]
Subject: Confirmation accepted
Date: Thu, 23 Oct 2003 15:45:23 -0400 (EDT)
Message-ID: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Precedence: bulk
X-Delivery-Agent: TMDA/0.57
Your confirmation was accepted, and so your original message has been
delivered.
[ This notice was generated by TMDA/0.57 (http://tmda.sf.net/),
an automated junk-mail reduction system. ]
--- Enclosed is a copy of your confirmation.
>From [EMAIL PROTECTED] Thu Oct 23 15:45:22 2003
Return-Path: <[EMAIL PROTECTED]>
Received: from segfault.monkeys.com (segfault.monkeys.com [66.60.159.24])
by falstaff.isc-net.upenn.edu (8.12.9/8.12.3) with ESMTP id h9NJjLvS0317
12
for <[EMAIL PROTECTED]>;
Thu, 23 Oct 2003 15:45:22 -0400 (EDT)
Received: from monkeys.com (unknown [127.0.0.1])
by segfault.monkeys.com (Postfix) with ESMTP id 3477041F58
for <[EMAIL PROTECTED]>;
Thu, 23 Oct 2003 12:45:21 -0700 (PDT)
To: [EMAIL PROTECTED]
Subject: Re: Please confirm your message to Andy Diller
In-reply-to: Your message of Thu, 23 Oct 2003 15:43:43 -0400.
<[EMAIL PROTECTED]>
Date: Thu, 23 Oct 2003 12:45:21 -0700
Message-ID: <[EMAIL PROTECTED]>
From: "Ronald F. Guilmette" <[EMAIL PROTECTED]>
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
