RE: [Asrg] 6. Proposals - CRI Draft - 4.1 Loop Avoidance

["Eric Dean" <eric@purespeed.com>]

> Isn't CRI about getting various CR systems to interoperate?

CR requires human intervention...CRI is automated.
 
> If something make sense for CR, how can it not make sense for CRI?
> 
> > The problem I have with the original sender's
> > email address is that I now have to inspect EVERY email
> > 821,822,and MIME to look for CRI headers.
> 
> This statement confuses me even further. If CRI systems don't use the
> original sender's email address, they DEFINITELY have to inspect every
> email for CRI headers because they don't know if a given email is a
> challenge or not.

Hmm...either way you have to inspect all headers.  I was thinking of
inspecting responses...but I still need to fully inspect 821,822,MIME
for challenges as well...unless there was a preemptive message by a CRI
challenging server requesting from the destination MX if they support
CRI...then the CRI message could go to a local system user rather than
the end-user...but that seems too complicated at this point.

However, I am thinking of a potential conflict whereby I may use CRI
client software via a CRI server...I need to think about this a bit
more...but if the CRI server uses my email address...then it may break
my client CRI software.

> I submit to you that keeping the original sender's email address
> SIGNIFICANTLY reduces overhead, because:
> 1. Challenge transmissions are ALWAYS a reactive step, (CRI draft, 2b)
> 2. This implies that the sender has already sent an email (CRI draft,
> 2a)
> 3. And if we ASSUME  that the original sender has automatically
> whitelisted the recipient email address (a safe assumption)

This makes sense when a computer is not automatically responding...when
a human is involved...whitelists matter...when it's a computer
maintaining state on the human's behalf...whitelists don't come into
play

> 4. Then a CRI system only needs to inspect email whose MAIL-FROM is
> present on the whitelist, otherwise the CRI needs to inspect
everything.



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg