You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Michael Hutchinson <mh...@manux.co.nz> on 2008/09/16 03:02:15 UTC

SPAM message received - but should not have been delivered.

Hello everyone.

 

I regularly do a Bayes training run every week on any missed Spam that I
collect from various places on the network. I picked some up from a
co-worker and began to analyse the headers to determine any Spammyness I
could write a S.A rule to bump the score up with. This is when I noticed
that the E-Mail message in question should not have hit our servers at
all - there is no header information suggesting a recipient that might
exist on our network or domains. There are recipients... don't get me
wrong... as well as Carbon Copy addresses - none of these addresses are
hosted with us at all - and yet the Mail Message in question was
delivered to my co-worker who's address has the same domain as my own
(Manux.co.nz).

 

The Headers for the E-Mail have been posted at pastebin:
http://pastebin.com/m5bcefa6a

The E-Mail itself has been posted at pastebin:
http://pastebin.com/m8827fb6

 

We host 2 Exchange servers as well as 2 Qmail servers. Everything
usually works fine between the four - no weird delivery issues, no rogue
E-Mails etcetera.

 

So, does anyone have a clue as to why the E-Mail in question was
delivered to our domain? Or even, why would our servers try to deliver a
message who's recipients don't exist here? 

 

Thanks for any help in advance,

Cheers,

Michael Hutchinson

Manux Solutions Ltd

| Phone: 0800 328 324

| Email: mhutchinson@manux.co.nz

| Web:   http://www.manux.co.nz/ 

 


Re: SPAM message received - but should not have been delivered. [Solved]

Posted by mouss <mo...@netoyen.net>.
Michael Hutchinson wrote:
> Hello Matt,
> 
>>> So, does anyone have a clue as to why the E-Mail in question was
>>> delivered to our domain? Or even, why would our servers try to
> deliver
>>> a message who's recipients don't exist here?
>>>
>> I see nothing in those headers that would indicate who the recipients
> are.
>> To:. Cc, etc are purely decorative. They mean *nothing* about who the
>> message is actually being sent to.
>>
>> Messages are delivered based on the address passed during the RCPT TO:
>> command in the SMTP session. This is also called the "Envelope
>> recipients". This information may sometimes be added to the email with
> a
>> "for" clause in a Received: header, but it is generally not present in
>> the message headers.
> 
> Ah, that explains everything - I feel a bit stupid now. I found it
> interesting to learn that RCPT TO information at SMTP time doesn't get
> recorded in the mail headers, otherwise this would be useful information
> to help build domain specific S.A rules.
> 

depends on your "delivery agent".

some MTAs add a Delivered-To header. but again, this is done at 
_delivery_ time when only one receipient is concerned (otherwise, it 
would expose Bcc recipients).

RE: SPAM message received - but should not have been delivered. [Solved]

Posted by Michael Hutchinson <mh...@manux.co.nz>.
Hello Matt,

> > So, does anyone have a clue as to why the E-Mail in question was
> > delivered to our domain? Or even, why would our servers try to
deliver
> > a message who's recipients don't exist here?
> >
> I see nothing in those headers that would indicate who the recipients
are.
> 
> To:. Cc, etc are purely decorative. They mean *nothing* about who the
> message is actually being sent to.
> 
> Messages are delivered based on the address passed during the RCPT TO:
> command in the SMTP session. This is also called the "Envelope
> recipients". This information may sometimes be added to the email with
a
> "for" clause in a Received: header, but it is generally not present in
> the message headers.

Ah, that explains everything - I feel a bit stupid now. I found it
interesting to learn that RCPT TO information at SMTP time doesn't get
recorded in the mail headers, otherwise this would be useful information
to help build domain specific S.A rules.

> It's actually rather common for To/Cc to differ from the envelope
> recipients. This is actually how Bcc's work, and it also happens on
> mailing lists. You'll get copies of messages posted to the list, even
> though when you look at the headers they're "To:
> users@spamassassin.apache.org"... the apache listserv turns around and
> Bcc's all the messages it gets to all of its recipients.

Well, that does make good sense.

Thank-you Matt for the quick and informative reply :)

Cheers,
Michael Hutchinson
Manux Solutions Ltd


Re: SPAM message received - but should not have been delivered.

Posted by Matt Kettler <mk...@verizon.net>.
Michael Hutchinson wrote:
>
> Hello everyone.
>
>  
>
> I regularly do a Bayes training run every week on any missed Spam that
> I collect from various places on the network. I picked some up from a
> co-worker and began to analyse the headers to determine any Spammyness
> I could write a S.A rule to bump the score up with. This is when I
> noticed that the E-Mail message in question should not have hit our
> servers at all – there is no header information suggesting a recipient
> that might exist on our network or domains. There are recipients…
> don’t get me wrong… as well as Carbon Copy addresses – none of these
> addresses are hosted with us at all – and yet the Mail Message in
> question was delivered to my co-worker who’s address has the same
> domain as my own (Manux.co.nz).
>
>  
>
> The Headers for the E-Mail have been posted at pastebin:
> http://pastebin.com/m5bcefa6a
>
> The E-Mail itself has been posted at pastebin:
> http://pastebin.com/m8827fb6
>
>  
>
> We host 2 Exchange servers as well as 2 Qmail servers. Everything
> usually works fine between the four – no weird delivery issues, no
> rogue E-Mails etcetera.
>
>  
>
> So, does anyone have a clue as to why the E-Mail in question was
> delivered to our domain? Or even, why would our servers try to deliver
> a message who’s recipients don’t exist here?
>
I see nothing in those headers that would indicate who the recipients are.

To:. Cc, etc are purely decorative. They mean *nothing* about who the
message is actually being sent to.

Messages are delivered based on the address passed during the RCPT TO:
command in the SMTP session. This is also called the "Envelope
recipients". This information may sometimes be added to the email with a
"for" clause in a Received: header, but it is generally not present in
the message headers.

It's actually rather common for To/Cc to differ from the envelope
recipients. This is actually how Bcc's work, and it also happens on
mailing lists. You'll get copies of messages posted to the list, even
though when you look at the headers they're "To:
users@spamassassin.apache.org"... the apache listserv turns around and
Bcc's all the messages it gets to all of its recipients.