I have been receiving the following messages in my maillog:

Aug 28 14:21:44 mail sm-mta[15540]: STARTTLS=server,
relay=host234.companya.com [65.218.114.XXX], version=TLSv1/SSLv3,
verify=FAIL, cipher=EDH-DSS-DES-CBC3-SHA, bits=168/168

Aug 28 14:21:44 mail sm-mta[15540]: l7SJLhXB015540:
ruleset=CheckMessageId, arg1=<9b8e85b6-da30-4786-9d24-217d43a0ddf2>,
relay=host234.companya.com [65.218.114.XXX], reject=553 5.0.0 Header
Error

Aug 28 14:21:44 mail sm-mta[15540]: l7SJLhXB015540:
from=<CustomerService [at] companya.com>, size=780, class=0, nrcpts=1,
msgid=<9b8e85b6-da30-4786-9d24-217d43a0ddf2>, proto=ESMTP, daemon=MTA,
relay=host234.companya.com [65.218.114.XXX]

My understanding is that Company A is sending these e-mails with an
invalid Message-ID and my sendmail configuration is designed to reject
invalid Message-IDs with a 553 Header Error.

Is there a way to selectively tell sendmail to accept e-mails from
company a, specifically CustomerService [at] companya.com, regardless of it
having an invalid Message-ID without completely removing the
CheckMessageId ruleset?

I tried adding "companya.com OK" to my /etc/mail/access file and
sendmail still rejected the e-mails.

My system is a default OpenBSD 3.9 with sendmail specs:
Version 8.13.4
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8
MIME8TO7
NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS
PIPELINING SASLv2
SCANF STARTTLS TCPWRAPPERS USERDB XDEBUG

Thanks for any help,
Kareem

In article <1188484606.329121.166080 [at] 57g2000hsv.googlegroups.com>
kareemy [at] gmail.com writes:
>
>My understanding is that Company A is sending these e-mails with an
>invalid Message-ID and my sendmail configuration is designed to reject
>invalid Message-IDs with a 553 Header Error.

Correct.

>Is there a way to selectively tell sendmail to accept e-mails from
>company a, specifically CustomerService [at] companya.com, regardless of it
>having an invalid Message-ID without completely removing the
>CheckMessageId ruleset?

Of course:-), but it requires adding rules to your CheckMessageId
ruleset, checking the envelope sender (available as $&f) - access db
won't affect it. Well, you could of course add rules that checked access
db. But I think you're really better off removing it, the only purpose
it has is to catch stupid spambots that can't even produce a message
with RFC-compliant syntax, of which there are probably close to zero
these days.

In general, checking for things that are only "incidental" indications
of spam, as opposed to something the spammer actually *needs* to do, is
pretty pointless - the spambot can just put <random-string [at] foo.bar> as
Message-ID and your rule will be happy, so of course that's what will
happen.

--Per Hedeland
per [at] hedeland.org

In article <fb7gpe$1gqa$1 [at] hedeland.org>,
per [at] hedeland.org (Per Hedeland) wrote:

> In general, checking for things that are only "incidental" indications
> of spam, as opposed to something the spammer actually *needs* to do, is
> pretty pointless

Not really. Stopping today's spam is a useful point.

I have rules matching a wide collection of Message-ID, Subject, and
envelope sender local-part patterns which result in the rejection of a
lot of spam and a steady stream of current spam into a Bayesian database
(which is the ultimate collection of 'incidental' indications of spam)
and many of those patterns have remained useful for many months. There
are even a few that I've shared with others (spreading the negative
feedback) that have failed to abate for a long time.

Not all spammers are as fast to react as the guys behind Storm. Some
appear to respond to dropping acceptance rates only by sending more spam
just like the stuff that fails. Even the classes of spam like Storm
where there is constant change, some patterns last for weeks and are
useful for that long.

Unfortunately, things spammers *need* to do are things that non-spammers
*need* to do. The stop a decent fraction of spam (say, >98%) you need to
work with things that spammers just find useful or just happen to be
doing currently, but which they could change at any time if they saw the
need.

--
Now where did I hide that website...