RE: The open relay problem.

On Wednesday March 24, [email protected] wrote:
> On Wed, 2004-03-24 at 16:17 +1100, Neil Brown wrote:
> > I think the idea of putting a crypto-cookie in the headers of all
> > outgoing mail is worth pursuing.  I think it has been mentioned on one
> > of these lists before, but I'm not sure if there was much conclusion.
> 
> I suspect that too many mailers return bounces without enough of the
> original message included. I asked if anyone had numbers to confirm or
> refute that, but nobody obliged.

I just got one :-(  Content below if you are interested.

It does seem to make universal SRS more attractive, and the arguments
against it are hard to sustain.

I would just really like a fairly reliable "sender" address, and some
indication of how reliable it was.  MAIL FROM seemed to be that, and
SPF seemed to give a good measure of reliability.  But if people start
re-writing the MAIL FROM header whole-sale, and quite possibly in
subtly different ways, then that seems to put a big hole in what I
thought SPF would give me.


NeilBrown




Here is the body of the message.... Maybe if the crypto cooke were put
as a comment on the end of the Date: line .... no, that's just silly.
-----------------------------


Attention: [email protected]


A problem was found in an Email message you sent. 
This Email scanner intercepted it and stopped the entire message
reaching its destination. 

The problem was reported to be: 

 the W32/Netsky.p@MM virus !!!


Please contact your IT support personnel with any queries regarding this 
policy.


Your message was sent with the following envelope:

MAIL FROM: [email protected]
RCPT TO:   [email protected] 

... and with the following headers:

---
MAILFROM: [email protected]
Received: from unknown (HELO vector.com.cn) (218.18.130.204)
  by ns1.vector.com.cn with SMTP; 25 Mar 2004 03:31:27 -0000
From: [email protected]
To: [email protected]
Subject: Mail Delivery (failure [email protected])
Date: Thu, 25 Mar 2004 11:24:12 +0800
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_001B_01C0CA80.6B015D10"
X-Priority: 3
X-MSMail-Priority: Normal


---