This may just be an issue of semantics. Perhaps what I'm suggesting is
more of a BCP than an adjustment to CRI. So maybe the right approach is
to solidfy the BCP for CR and then make sure your CRI examples respect
the BCP.
-----Original Message-----
From: Eric Dean [mailto:eric(_at_)purespeed(_dot_)com]
Sent: Thursday, October 02, 2003 7:43 AM
To: 'Yakov Shafranovich'; Peter Kay
Cc: 'Kee Hinckley'; asrg(_at_)ietf(_dot_)org; 'Brad Knowles'
Subject: RE: [Asrg] 6. Proposals - CRI Draft - 4.1 Loop Avoidance
I wouldn't call it a basis...it's certainly good experience
from someone who understands CR systems.
Again, let's not confuse CR with CRI which simply handles
automation and loop avoidance.
-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org
[mailto:asrg-admin(_at_)ietf(_dot_)org] On Behalf Of
Yakov
Shafranovich
Sent: Thursday, October 02, 2003 12:49 PM
To: Peter Kay
Cc: Kee Hinckley; Eric Dean; asrg(_at_)ietf(_dot_)org; Brad Knowles
Subject: Re: [Asrg] 6. Proposals - CRI Draft - 4.1 Loop Avoidance
FYI, Brad Templenton has a BCP for C/R which we can use as
a basis for
our BCP:
http://www.templetons.com/brad/spam/challengeresponse.html
Peter Kay wrote:
This is interesting as it may pave the way to a BCP as well.
Kee, I'm curious, did your support system autorespond
with the same
RCPT-TO address as the one the customer sent it to?
Meaning, if the customer sent an email to
"support(_at_)domain(_dot_)com", did
your
autoresponder reply with a RCPT-TO of
"support(_at_)domain(_dot_)com" or was it
"techsupportreply(_at_)domain(_dot_)com".
-----Original Message-----
From: Kee Hinckley [mailto:nazgul(_at_)somewhere(_dot_)com]
Sent: Wednesday, October 01, 2003 4:46 PM
To: Eric Dean
Cc: Peter Kay; asrg(_at_)ietf(_dot_)org
Subject: RE: [Asrg] 6. Proposals - CRI Draft - 4.1 Loop Avoidance
At 8:30 PM -0400 10/1/03, Eric Dean wrote:
If we start adding various messaging such as with DSNs...I
don't think
that we should be hijacking a sender's email address to
carry various
protocol information.
Perhaps. Just keep in mind that you need to interoperate
with more
than just other CR systems.
As an example, a user of a CR system sent mail to our support
system.
Our spam filters validated the sending email address by
doing a MAIL
FROM/RCPT TO. Then we generated an auto-reply. His CR system
rejected the our auto-reply and we got a bounce report from our
server. Then the CR system sent us two challenges. One
went to the
support system, but it didn't use the same subject, so it didn't
have
the ticket number, so it generated a new ticket, to which we
responded (fortunately the CR system didn't challenge
that as well).
The other challenge was generated by the CR mail server, which
generates challenges when it gets a RCPT TO, rather than when it
gets
a message (and they aren't the only ones who use that
stunt). That
reply went to a trap address that we use for the MAIL FROM--so no
damage there, just annoyance.
So here's the count of messages sent.
User - 1
Support System - 2
CR System - 2
And of course we have a bogus support ticket to clear
out. And the
user doesn't get any feedback that we've gotten their
support
request until it moves through the queue to a human. At
which point
our support folks have to go to the web site and answer the
challenge.
--
Kee Hinckley
http://www.messagefire.com/ Next Generation Spam Defense
http://commons.somewhere.com/buzz/ Writings on Technology and
Society
I'm not sure which upsets me more: that people are so
unwilling to
accept responsibility for their own actions, or that they are so
eager to regulate everyone else's.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg