Spam's been getting through Postini lately that's addressed to a recipient ([email protected]) in the To: field and in the headers. While this isn't that strange -- we've had spam get through before -- the fact that I can't tell how mail addressed to [email protected] is going to myself and at least one other staff member.
The headers show that it's being received by Postini's gateway and sent to our Exchange Server, but spam or not, that shouldn't effect routing at all. None of us are getting any "regular" mail that's addressed to [email protected], just these spam messages. Just to make sure I wasn't crazy I telnet'ed into the Exchange Server from another machine and sent a message to [email protected] and none of us got it.
I checked to see if there's delivery options with a forwarder on his Exchange mailbox, but there's none. I also checked to see if some distribution group was setup and there isn't.
Again, all of these checks I've done seem pointless because the rcpt to
determines to what address delivery is attempted. I've turned on diagnostics logging to see if anything odd turns up but the Outlook headers shouldn't "lie", should they? Anything else I'm missing? We're running Exchange 2007 (SBS 2008).
This is just a BCC (Blind Carbon Copy). Test it by sending mail to [email protected] and BCCing yourself. It was originally specified in RFC 733 (replaced by RFC822 and later by RFC2822). Both RFC 2821 and RFC 2822 mention issues with BCC (see Security Considerations section).
The headers could say "To: The Whole World ", it means nothing to the actual routing and delivery of the message. The
rcpt to:<[email protected]>
is the only thing that matters; most servers also put the 'rcpt to' in the 'Received' header line.Edit:
For example, I got an e-mail yesterday with these headers:
In my e-mail reader it say "To: freebsd-announce[at]freebsd.org" and nothing at all about my e-mail address. If your running Exchange the e-mail has to come from an SMTP source for it to have the Received header; Exchange does not follow RFCs for internal e-mail.