At 09:22 2002-04-30 +0100, Edward Wildgoose did say:
On Mon, 29 Apr 2002, Professional Software Engineering wrote:
[snip]
Your quote levels were hosed - I wrote the initial reply, but not the two
paragraphs below that, which your attribution implies I wrote.
It is immaterial to the procmail list if exim or qmail, postfix, sendmail,
or whatever adds a nonstandard header: how to access it from within
procmail is fine (and was already explained in my original post, which
makes THAT moot). If it isn't a standard header it certainly isn't
procmail's fault for not implementing it, and if it IS a nonstandard
header, it's the procmail developers' perrogative to implement support for
it as they see fit - nobody is forced to use the macros, and nobody is
restricted to using only the macros, which are there to simplify some
common matching tasks.
The whole point was that the original post was making it out as if procmail
was at fault for failing to provide a match condition for this non-standard
header added by Exim, and I contend that it is not. I further contend that
if anybody is at fault for issues with nonstandard headers, it's be the MTA
or other process which is adding them in the first place -- on messages
which may be interpreted locally or forwarded elsewhere - rather than
endeavouring to adhere to accepted (and documented) standards. The X-
prefix has long been accepted as the method to prefix a nonstandard header
element (X-Mailer, X-Sender, X-Loop, X-Envelope-From, X-Envelope-To,
X-UIUD, X-Priority, etc)
I provided the solution for that user, so rather than coming to the defence
of every mail program that adds undocumented headers to messages (perhaps
it was the comparison to a Microsoft product that established this need to
defend your MTA of choice?), perhaps people could accept that the problem
lies within whatever MTA, and if they choose to use that MTA, they choose
to accept whatever quirks it may have. That doesn't make it a procmail issue.
Which is also why my original followup to the first qmail post was sent
offlist. In that reply, I also pointed out that there's nothing stopping
the developers of these MTAs from drafting an RFC documenting their
extensions, yet they have not done so.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail