At 08:49 AM 3/18/98 -0800, Michael Helm wrote:
Message-Id: <"OP-MIME expo400:439*""
<allanm(_at_)op(_dot_)x400(_dot_)icl(_dot_)co(_dot_)uk>"@MHS>
^ ^ ^ ^ ^ ^
It looks like the rule doesn't like things like whitespace/\n
inside <>.
Yea, you're right. From my message yesterday:
-- quote
[^ <>@]+(_at_)[^ <>@]+
^^^^^^^^^^ ^^^^^^^^^^^
Between the brackets but before and after the required '@', we expect to
find at least ONE character which is NOT a space, tab, '<', '>' or '@'.
Your messageid matches this fine.
-- quote
I blindly overlooked that there is no '.*' preceeding or following that
(because I'd broken the regexp down into portions, and was ignoring
everything outside the portion I was looking at).
Modifying this portion to something more like this:
.*[^ <>@]+(_at_)[^ <>@]+.*
would allow for this sort of thing, but at the same time make sure that the
messageid contains an '@' and a non-badchar immediatley to either side of
it -- without reguard for whatever else might be there.
No, this doens't bring it up to snuff with RFC parsing, but it would
probably fix your current problem.
In the first case the \n probably tripped it; in
the above case it does not see & special-process the quotes.
<XY(_at_)MHS> should be a legal Message-ID field.
Yes, so long as you're not using that in some way to indentify uniqueness.. :)
Generally speaking, rather than filter messages via an attempt at
confirming valid messageids (in which case many broken mailers are going to
give you grief, if not the ones that attempt to unneccissarily push the
spec), why not filter OUT the KNOWN INVALID ones? No messageid, null body
messageid, messageid equal to the from address, etc?
Ok then -- should I complain about the 1st message id, with
the interpolated \n's, & how can the correct quoting rule
be done?
Using sed? Output the results to a DEMANGLEDMESSAGEID variable or somesuch
if you're going to use it in multiple places.
As for newlines, I would have thought that Procmail would have
reconcatenated it into a single line, ala To, cc, and received. I don't
think there'd be any newlines in it at that point. Could someone more
knowledgeable about such internals confirm?
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395