>>So, looking at: >> >>"/GUID:QPywoUg6DZ06+yvqCupCVJw*/G=Cam/S=Dowlat/OU=Corporate-Markham/O=A >>lcate l Cable/PRMD=ACAB/ADMD=ATTMAIL/C=CA/"@MHS >> >>"-GUID:QnGodydG460CKmx35BCOvbw*-G=Cam-S=Dowlat-OU=Corporate-Markham-O=A >>lcate l Cable-PRMD=ACAB-ADMD=ATTMAIL-C=CA-"@MHS > >Looking at the rule, I'm surprised they aren't BOTH declared invalid. >[RFC quoting deleted on why a space isn't legal in msg-id]
Ok, I buy that. And as another poster pointed out, they both were ruled that why for him. You see, we run SpamAssassin on our perimeter MTA so that we can reject messages that score a 10 or higher at SMTP time. While 5 or higher is marked as spam but still delivered. All the specific rules for rejected messages are logged, but not for accepted messages. I'd assumed that the past message log I looked at, since it wasn't even marked as spam, wouldn't have had enough of a negative score to overcome the 20 I'd put the INVALID_MSGID rule at. But I see that assumption must have been incorrect... >[Different poster] BTW, why have *any* single rule scored at 20? Especially this one. To be able to not accept "obvious" spam at the perimeter, this machine is our incoming SMTP gateway. However, after it accepts a message for delivery, it still must pass the message off to our Internet firewall for delivery. The firewall, as configured from the vendor, has a rule to reject e-mail with invalid message id's. Assuming both would reject/accept identically for a given msg-id, it made sense to reject it right away, rather then accepting it for delivery and then having the firewall end up trying to delivery an NDA message to the sender. Which is what did occur frequently before I raised that rule to 20. However, it seems the rule on the firewall doesn't mind spaces in the msg-id, as it did let the message in once I restored the normal score to INVALID_MSGID. Which makes sense from a firewall perspective, I suppose. To them, they're not trying to prevent spam, but possible malicious headers which might cause internal e-mail machines to be compromised by such things as buffer overflows when processing the e-mail. In that light, it's hard to imagine a space character causing much of an issue with any MTA.
