SPAM message received - but should not have been delivered. - SpamAssassin

This is a discussion on SPAM message received - but should not have been delivered. - SpamAssassin ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

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

  1. 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/





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

    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.


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

    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


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

    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).


+ Reply to Thread