procmail
[Top] [All Lists]

Re: anybody see this spam?

1997-05-07 15:24:00

Update: I was able to generate this mail appearance simply by submitting
an smtp session with an empty envelope sender <> to a system that forwards
to me. I was able to create this appearance:

From Mailer-Daemon  Wed May  7 14:38:41 1997
Return-Path: <Mailer-Daemon>
Received: from mailbox2.ucsd.edu by darwin1.ucsd.edu (SMI-8.6/SMI-SVR4)
      id OAA01497; Wed, 7 May 1997 14:38:40 -0700
From: Mailer-Daemon
Received: from darwin1 (darwin1.ucsd.edu [132.239.180.3]) by mailbox2.ucsd.edu 
(8.8.5/8.6.9) with SMTP id OAA23779 for corrigan(_at_)ucsd; Wed, 7 May 1997 
14:38:22 -0700 (PDT)
Date: Wed, 7 May 1997 14:38:22 -0700 (PDT)
Message-Id: <199705072138(_dot_)OAA23779(_at_)mailbox2(_dot_)ucsd(_dot_)edu>
Apparently-To: <sysmjc(_at_)darwin1(_dot_)ucsd(_dot_)edu>

Sounds like a case you didn't allow for.

Your mailer daemon maybe has a @ in the address in the From: line ?

So after all this it wasn't an attempt at SPAM then? ie. there's no other
smarts that try to deceive the filters in there is there so it was just a
case that we currently don't allow for.

Cool. 


So how does one differentiate b/w real bounces from my mailer daemon and
this bogus message?

On Wed, 7 May 1997, Michael J. Corrigan wrote:


...
From: Mailer-Daemon

...

Also this header appears in the middle of the received stream (which make
s
me rather suspicious of the received lines appearing after it (possibly
forged), though I don't know if there is anything in RFC822 that prohibit
s
this ordering).
...

This means that no From: header was present in the original message and als
o
that the originating system did not have the flag set in sendmail to 
automatically add From: headers if they are not present. Then a later host
did have that flag set so the From: header got added. Sendmail adds the hea
der
atop the received lines that are already present. It looks unusual because
it is unusual. Most systems have the flag set and so one usually sees a Fro
m:
header down below all the received headers (although certain client sendmai
l
configurations (nullclient.cf) produce this dislocated From: header locatio
n,
I believe).



<Prev in Thread] Current Thread [Next in Thread>