In message <[EMAIL PROTECTED]>, you wrote:
>It is much easier to talk about this is you talk to us instead of
>down to us...
It is also much easier to talk to people about technical issues if they
don't try to use stupid do-nothing government service type excuses for
what are clearly software flaws.
Look, I am a software engineer too. And I understand as well as anyone
the pride of authorship that a software engineer often feels for his own
code. What I do not understand however, and what I do not excuse, is
these kinds of lame "There is no law that FORCES us to clean up this
toxic waste dump" excuses that some people like to use in place of
rational arguments whenever they feel like taking a bug report against
their own code personally.
If you guys are only working on TMDA for the sake of the lift that it
gives your own egos, then fine. In that case I will go away now and
you can have my apology for having bothered you. On the other hand,
if you are actually interested in improving its quality and usefulness,
then just saying ``Which RFC requires us to NOT make this package (TMDA)
a pile of bat guano?'' is kind of a stupid thing to say.
No, I admit it, freely and without duress. No RFC explicitly prohibits
you from coding up a useless pile of doggy doo, if that is what you really
want to do.
So can we move on now?
Forget about the minimal requirements of the published RFCs. As least
with respect to e-mail, they don't even tell half of the story, AND in
at least one glaringly obvious case, nobody in their right mind even
follows them anymore. (Did we forget about the ``Be liberal in what
you accept'' edict of the SMTP-related RFCs, eh? Every user and site
that does any kind of spam filtering these days... which is to say
upwards of 75% of everybody... is BREAKING that RFC rule, even as we
speak. And nobody gives a shit, because there is reality, out here in
the real world, and then there are RFCs. The two are only sometimes
mutually compatable.)
>FWIW I implemented an SMTP gateway about 20 years ago
>on the MIT PhoneNet project in the very early days...
Swell. Then _you_ are probably enough of a pragmatist to recognize a
dumb question when you see one, e.g. the one about RFCs that already
got fires in my direction when I just tried to point out a simple and
BLATANTLY OBVIOUS bug. (Hint: One single autoresponse message != "bulk".
Like DUH!)
>Some of us do have a clue what is going on,
Prove it.
Fix the three bugs I reported.
>so instead of trying to prove how bad you think TMDA is
I'm not trying to do that. I just don't have a lot of patience, especially
for stupid arguments.
Look, an autoresponse message is NOT a "bulk" message. If you have at
least a couple of functioning brain cells to rub together, then you can
understand that obvious point. This isn't like subtle or anything, and
if you comprehend the English language and if you are not a retard, then
you don't need an RFC to explain it to you.
>why not make suggestions and provide references
Reference for "bulk":
Webster's New English Dictionary
Reference for "junk":
The last 1,000 automated response message you have received from
the entire Internet. (You _DO_ save your old e-mails to use as a
good reference for current common practice with respect to e-mail,
RIGHT? I do, even if you don't.)
>and let the other smart people on this list consider your points?
Consider away.
>> Yes. TMDA challenges and/or TMDA "confirmation confirmations" will
>
>Great! I think we like to fix bugs
>
>> _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.
>
>What packages?
You want ME to do your reserach for you?
Forget it. I'll just turn the question around so that the onus is back
on you: Show me e-mail messages... ANY e-mail messages... that were auto-
matically generated one-shot (singular) messages and that contain:
Precedence: bulk
other than those generated by TMDA (which is broken).
For every one of those you can show me, I can show you THREE autoresponse
messages that have the correct encoding, i.e.:
Precedence: junk
Why? Because most implementors _do_ comprehend _either_ the traditional
meaning _or_ the dictionary meaning (or both) of the word ``bulk'' , un-
like present company.
>> 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.
>
>To re-phrase that:
>
>>> 2) You might want to consider including the Message-ID: of the
>>> message that it is a response to, either in an In-Reply-To:
>>> header or in a References: header.
Phrase it any way you want.
I know what you should do, and you know what you should do.
Generating an In-Reply-To header for TMDA's automated replies is a no-
brainer.
>> 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).
>
>> No human and no autoresponder should be using null envelope sender
>> addresses for any purpose other than UNDELIVERABLE BOUNCE notifi-
>> cations.
>
>That sounds right too, but since the handling of that can get strange
>I'll let jason address that one.
Fine.
>Looking at your message I see you are using Version 0.57,
You misunderstood. _I_ am not using TMDA at all. Rather, I am building
a filtering system which will be in some ways similar to, yet radically
different from TMDA. (It will also do challenge/response in some cases,
but at the SMTP transaction level, via text in 5xx responses.)
Ideally, that filter (i.e. _my_ filter) should allow an automatic ``pass
through'' of all legitimate TMDA challenge (and "confirmation confirmation")
messages _without_ trying to challenge THOSE messages. But as of now, the
TMDA automatically-generated messages _will_ be challenged by my filter,
precisely because you guys screwed up the formatting of the TMDA-generated
messages in _all_ of the three ways I have described. (If you had gotten
any one of these three things right, then there wouldn't have been any
problem. But you got three strikes in a row.)
>a lot of things have changed since we are now on 1.0...
>
>If we Talk TO each other we can get a LOT more done...
>
>tom
>
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
