Subject: RE: [Asrg] C/R Interworking Framework

From: "Peter Kay" <[email-masked]>
Date: Mon, 9 Jun 2003 08:20:29 -1000

> -----Original Message-----
> From: Scott Nelson [mailto:[email-masked]] 
> 
> At 06:24 PM 6/6/03 -1000, Peter Kay wrote:
> >I agree, a challenge can be seen as a DSN or a new message. 
> My point is 
> >that in either case, the MAIL FROM or REPLYTO should be 
> consistent with 
> >the challenger's email address, otherwise 2 C/R systems will 
> challenge 
> >each other's challenge.
> >
> 
> If you're sending a DSN, then the From: header could be your 
> address, but the MAIL FROM should probably be <>. That 
> prevents a lot of bad things from happening.
> 

I think DSN in the CR space is a matter of semantics and definition. I'm
not 100% whether a challenge email is a DSN or not, and like I said
earlier I can see a case for it ether way.

If you're saying that if it's a DSN, then the MAIL FROM s/b <>, then
I'll say that challenge emails are not DSNs.

> Setting the MAIL FROM to your address means that you could 
> end up challenging a non-existent address, then the 
> mailer_daemon that bounces the mail back to you. If the C/R 
> system was really broken, it could challenge bounces 
> from a non-existent address endlessly, but in the normal case 
> this is only twice as much work as you need to do.
> 

The MAIL FROM needs to be the address of the challenge sender in order
to allow CRI systems to interoperate. While some CR systems may inspect
the header, other systems that bounce the email outright (like ours)
need to look at the MAIL FROM, for reasons I've mentioned earlier in
this thread.

You are correct about that fact that you "could end up challenging a
non-existent address".  Most spammers use bad addresses.  Our system
handles mail that is bounced because of non-existent email and this also
results in reduced load on the MTS due to more intelligent mailer_daemon
handling.

Peter

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 09 Jun 2003 15:22:32 -0400

At 08:20 AM 6/9/2003 -1000, Peter Kay wrote:

>[...]

This would only be true for C/R systems that interoperate via plain SMTP. I 
don't think it would be a problem to use either an ESMTP extension that is 
defined for DSNs or to define an new ESMTP extension. This way you will get 
around the MAIL FROM<> requirement that is mandated by the RFCs by passing 
the C/R information via such extension.

ALSO, not all C/R systems are using the MAIL FROM <>. Earthlink for 
example, sends out all of its challenges from the same email address 
<[email-masked]> (see 
http://www.washingtonpost.com/wp-dyn/articles/A26774-2003Jun6.html).

Yakov

---

From: Rob Cameron <[email-masked]>
Date: Mon, 9 Jun 2003 13:32:46 -0700

It is hard to keep up with the volume of this list.   However,
here are some of my thoughts on how C/R systems should
use existing headers.

Although there are good arguments in favour of issuing
challenges to the MAIL FROM envelope header when
it differs from the RFC 2822 From: field, I do not think
that C/R systems should consider challenges to be delivery
status notifications (DSNs).

(1)  A DSN is logically a communication from the MTA,
acting like a postal worker.   Some C/R systems will view a
challenge as a communication from the MUA, acting like a 
secretary. (In our research, we use the term e-secretary and
envisage a protocol to define the future interoperation of
e-secretaries to carry out a variety of low-level messaging
tasks on behalf of mailbox owners).

2) A DSN is designed as a terminal communication, in which
the MAIL FROM address <> is used to indicate that a reply 
should not be made.   But the purpose of a challenge, to a
legitimate sender, is to solicit a reply.

(3)  A challenge sent as a DSN is likely to be confusing
to a human who receives it, depending on MUA behaviour.

(4)  To automatically reply to challenges as DSNs, software 
that otherwise knows never to reply to a DSN will need to
be modified to violate this principle.    

For the purpose of the Internetworking Framework, I don't
think that we should assume that challenges/responses will only
be generated to the MAIL FROM field.   Rather, the framework
should be robust enough to handle challenges/responses to
either the envelope MAIL FROM or the From: message field.

Indeed, I think that the framework should make a statement
something like the following.

"In formulating a challenge message, a C/R system should use
the MAIL FROM envelope header and the from, reply-to
and sender message headers for appropriate purposes.   However, 
a C/R system must ensure that it is capable of receiving and
correctly processing a response sent to any address mentioned in
any of these fields."

Beyond this, I also think that C/R systems should be required
to provide full support for message-id, in-reply-to and references
headers.  That is, the framework should state that challenges
and responses must (not should) provide a unique message-id
and must (not should) properly form in-reply-to and references
headers from prior e-mails in the chain.    By implementing these
RFC2822 recommendations, C/R systems will give each other
valuable information to address both looping and spoofing
concerns.

---

From: Art Pollard <[email-masked]>
Date: Mon, 09 Jun 2003 16:21:19 -0600

>valuable information to address both looping and spoofing

I agree that we should have a references: header (just like the one in 
NNTP).  This would be useful for threading mail conversation threads among 
other things.  I have often wondered why current clients don't maintain 
this header and utilize it when available.  It would be so useful.

I think as has been mentioned previously in regards to CR systems in 
general (and I don't remember if it was mentioned in the CRI case), that 
what should happen is that the messages should be digitally signed by the 
sender.  The CR system would filter based in the digital signature rather 
than the FROM address.  Thus it would be quite possible for people to have 
multiple clients with the same digital signature (one for each e-mail 
address say) and they would only have to undergo the CR once -- even if 
they switched ISPs.  Furthermore, it would virtually eliminate spoofing 
since even if someone were able to obtain a previous copy of someone's mail 
and a list of all their friends, they still would be unable to spoof the 
digital signature.  When whitelisting occurred, it would whitelist a 
particular person's signature rather than their e-mail address.

I'm not sure if the CRI framework provides for this or not as I have a hard 
time keeping up with things (just as many in this list apparently do).

Is there a brief synopsis of the current state of the CRI framework so I 
can refresh my memory on everything? (Which would be much better than 
having to re-read all the CRI messages. ;-)

-Art
-- 
Art Pollard
http://www.lextek.com/
Suppliers of High Performance Text Retrieval Engines.