Greg Maples <greg(_at_)clari(_dot_)net> writes:
I promise that I won't post this a million times, but I would like some
pointers. Any help appreciated. Repost follows.
Perhaps no one answered because you didn't provide enough information
to figure out what's going on, and therefore the reply would mostly be
questions back to you and explanation of apparently unrelated
concepts. For instance, you should have explained your relation to
"netconnect.net". Without knowing that it's 'your' domain, your
question is almost nonsensical: "You don't like mail from
netconnect.net? Then /dev/null it!"
Any ideas on what recipe can be used to catch the 'for' entry below in a manner
that won't disturb valid mail?
...
Note the 'dbennett(_at_)netconnect(_dot_)net' entry. This is a mis-addressed
email,
probably intended for 'connect.net'. I'd like to filter for all non-valid
netconnect.net entries, and do so for valid 'TO' entries. There is no TO
line to filter this on though.
You'll have to be more specific about how to tell 'valid' messages
from 'invalid' messages. Is any message with a Received: header that
contains a "for" clause with an address in the netconnect.net domain
invalid? (probably not.)
Your mention of [doing so] "for valid 'TO' entries" sounds like you
want to examine the recipient address, and, if it's a valid address in
the netconnect.net domain, let the message through. This actually
brings up the question of how mail address to
<someone(_at_)netconnect(_dot_)net>
ends up being processed by procmail. Since netconnect.net appears to
be a virtual domain hosted by clari.net, I would guess you have a
sendmail mailertable entry on baroque.clari.net that specifies that
netconnect.net should be delivered via the procmail mailer, in which
case you should be _ignoring_ the To: header and instead making mail
routing decision based on the second argument given to procmail.
Failing to do so means that netconnect.net address will never be able
to subscribe to mailing-lists.
Perhaps you should consider the question, "why did whatever handles
netconnect.net route this message to me, given that I'm not
<dbennett(_at_)netconnect(_dot_)net>?" Once you answer that question, you
should
be able to change that mechanism to do otherwise.
Philip Guenther