On Thu, Jul 28, 2005 at 12:59:50PM -0500, David W. Tamkin wrote:
Dallman Ross wrote:
haven't yet seen the simplest, to my knowledge, way of catching an
empty or blank or just-angle-brackets header. This is it:
:0: # brackets contain caret, space, tab, angles
* ! ^From:.*[^ <>]
/dev/null
Good. It also will catch the absence of any From: header at all,
Yes, I forgot to mention that explicitly, though I meant to.
You and Ruud picked up on it, of course.
We can add other chars to the class. Single- and double-quotes
come to mind, as do parens. Put anything you want in there that
shouldn't be alone on the From line without alphanumerics.
It turns out that if you put a double-quote mark inside brackets
for a char class, it needs to be quoted. Okay, but it's hard to
remember, and it's ugly. If we set DQ to a double-quote char,
and use var assignment for some of the others, too, for
convenience's sake, it looks cleaner. Moreover, we can edit
the "bad" charset at will without messing with the recipe.
SPACE = ' '
TAB = ' '
WS = $SPACE$TAB
DQ = '"'
SQ = "'"
aBAD_CHARSET = $WS$DQ$SQ><)(
:0
* $! ^From:.*[^$aBAD_CHARSET]
/dev/null
Furthermore, why stop there? We can simply
say that if no low-bit ASCII char is present,
deep-six the message.
:0
* ! ^From:.*[a-z0-9]
/dev/null
We don't have to stop there. We can pre-define an address.
If there's no full email address, sh*tcan the mail.
(Don't do this if you allow local users to mail each
other and your system doesn't append the FQDN on the
address.]
I do exactly this in my own .procmailrc. If there's no
valid email address (and if the envelope-from isn't in
my whitelist), it goes in the spam pile.
At first this was harder to code than I wished for it to
be, until I remembered what I wrote earlier today about "not"
being the way out of many conundrums. See, the problem is
that many odd chars can be valid in an email address. I
didn't really want to rule them out. At first I had a
generous charset that I called "a useful charset for
local email-address parts." But, gee, if someone wants
to have an equals sign in his email address, and if the
transport mechanism will carry the message, who am I to
say no? The RFCs theoretically allow it. So let's define
what's *not* in an address (the local part), and do it
that way. And that's what I do!
Below is taken out of my current setup, with only minor
changes for public display. My nomenclature is to call
vars "FOOs" if it's a raw character set, and "FOO_CL" if
it's a class. That way, later I can remember, when I
employ the vars.
DQ = '"'
SQ = "'"
SPACE = ' '
TAB = ' '
NL = '
' WS = $SPACE$TAB
ALNUMs = a-zA-Z0-9 # low-ASCII alphanumeric set
xADDRs = ][><)($WS$NL,;:$DQ$SQ@ # local-address-excluded charset
ADDR_CL = [^${xADDRs}] # extended local-address class
HOST_CL = [${ALNUMs}-] # canonical host char-class
aTLD = [a-zA-Z][a-zA-Z]+ # com, net, org, uk, eu, etc.
aHOSTPART = (${HOST_CL}+[.])* # generic host string left part
aHOST = ${aHOSTPART}${HOST_CL}+ # generic host string
aFQDN = ${aHOST}[.]${aTLD} # generic canonical domain name
aADDR = ${ADDR_CL}+(_at_)${aFQDN} # generic email address
I have essentially that (very similar, just with some slight differences
to my naming scheme in that I'm now using _VAR for my vars so I don't
collide with other namespace) in a separate INCLUDERC (along with
other stuff, of course).
Now we're ready:
MATCH # unset to initialize
:0
* $ ^From:.*\/[^$WS].*
* $ MATCH ?? $aADDR
{ } H_FROM = $MATCH
:0 E
# could put a whitelist-check condition here if
# desired, to accept empty Froms from vetted parties
/dev/null
Enjoy!
Dallman
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail