Subject: [Asrg] Receiver Initiated Authentication

From: "Michael Kaplan" <[email-masked]>
Date: Sun, 16 Sep 2007 19:58:32 -0400

I propose a method of rapidly achieving a near comprehensive SPF database.
The core of this concept is that questionable unauthenticated email will be
bounced; the return of this bounce authenticates the domain.  This domain
and the MTA listed in the return path of the resent bounce is now entered
into a shared database.  All future emails from this previously
unauthenticated domain sent via this MTA will now be authenticated after
consulting this newly established database.

Existing SPF cannot authenticate forwarded email.  My proposal employees
multiple mechanisms to transparently overcome this other major flaw with SPF
so that even forwarded email is authenticated.

Existing authentication schemes are dependent on the participation of the
senders of email.  My proposal allows for the receiver to initiate the
process of authentication.  I therefore call this proposal Receiver
Initiated Authentication (RIA).  The process is detailed at:

http://spamfizzle.com

I argue that RIA will authenticate all questionable incoming email.
Innocent third parties will be relatively unaffected by erroneous bounces.
I also demonstrate how RIA is orders of magnitude superior to C/R.

Sincerely,

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

---

From: Steve Atkins <[email-masked]>
Date: Sun, 16 Sep 2007 18:49:11 -0700

On Sep 16, 2007, at 4:58 PM, Michael Kaplan wrote:

> I propose a method of rapidly achieving a near comprehensive SPF  
> database.  The core of this concept is that questionable  
> unauthenticated email will be bounced; the return of this bounce  
> authenticates the domain.  This domain and the MTA listed in the  
> return path of the resent bounce is now entered into a shared  
> database.  All future emails from this previously unauthenticated  
> domain sent via this MTA will now be authenticated after consulting  
> this newly established database.
>
> Existing SPF cannot authenticate forwarded email.  My proposal  
> employees multiple mechanisms to transparently overcome this other  
> major flaw with SPF so that even forwarded email is authenticated.
>
> Existing authentication schemes are dependent on the participation  
> of the senders of email.  My proposal allows for the receiver to  
> initiate the process of authentication.  I therefore call this  
> proposal Receiver Initiated Authentication (RIA).  The process is  
> detailed at:
>
> http://spamfizzle.com
>
>

It does seem to combine most of the worst anti-spam ideas of the past  
decade - it's got challenge-response, it's got "have to install new  
software in all MUAs to make it not suck", it's got graphical  
captchas in auto responses, it's got "each correspondent should use a  
different tagged address", it's got "you have to be able to read HTML  
email to make the captchas work".

The end result doesn't look as bad as you'd expect from combining all  
those things. There's not requirement to use a web browser (just a  
mail client that can handle html, images and possibly forms).

> I argue that RIA will authenticate all questionable incoming  
> email.  Innocent third parties will be relatively unaffected by  
> erroneous bounces.  I also demonstrate how RIA is orders of  
> magnitude superior to C/R.

That's a big claim.

It looks like the core of your approach is this:

1. If Spamassassin (or whatever tech) thinks the inbound mail to a  
tagged address is spam, permanently disable that tagged address and  
send a challenge-response to the From address, including a newly  
generated tagged address. Similarly for mail sent to a non-tagged  
address.

2. If the sender responds to the challenge, whitelist the IP  
address / domain combination. (Your description of this is very  
confusing,  and seems to be badly misusing the term SPF to refer to  
something completely unrelated, so I may be missing something there).

3. Install software in all end users MUAs to automatically intercept  
inbound challenges and respond to them.

4. For some domains ("suspicious domains") use a different approach,  
incompatible with the universally distributed software in (3) and  
require the recipient to manually resend the message, after answering  
a graphical captcha embedded in the challenge. This will require an  
MUA to handle HTML and render images within the client.

It seems that it will send unwanted email to strangers. It also seems  
to be more concerned with spam than with handling mail you actually  
want to receive. For example, the usual use of a tagged email address  
is to allow some entity to send you mail and avoid a lot of your  
normal content-based filters as only legitimate mail is expected to  
be sent to that tagged address. Terminating a compromised tagged  
address is something that'll happen very rarely, while having content  
that may trigger a content based filter sent to that tagged address  
may be fairly common in some cases. Your approach seems to consider  
only the rare case of a compromised tagged address, not the common  
case of a non-compromised tagged address.

Your use of the terms "SPF" and "bounce" in your description seem to  
differ widely from accepted usage, so you may want to clean up some  
of the descriptions if you're looking for broader feedback. You'll  
also want to discuss why you believe this will not impact legitimate  
bulk email, such as mailing lists, as that's not clear from your  
current discussion.

Cheers,
   Steve

---

From: "Michael Kaplan" <[email-masked]>
Date: Sun, 16 Sep 2007 22:29:28 -0400

> decade - it's got challenge-response,

Section 12 details how  this system is orders of  magnitude better than C/R

it's got "have to install new
> software in all MUAs to make it not suck"

Even without a very simple (section 5.2) upgrade to MUAs the system will be
unseen by almost every legitimate sender.

, it's got graphical
> captchas in auto responses,

As referenced at the top of section six this will likely only be sent bulk
senders with less-than-ideal sending practices.  Other senders whose domains
are under spammer control will also be receive graphical CAPTCHA (I guess it
depends on how much sympathy you have for a compromised sender with a server
sending a thousand ham a day along with a million spam).

it's got "each correspondent should use a
> different tagged address"

They should, but they certainly don't have to.  How is this a problem

, it's got "you have to be able to read HTML
> email to make the captchas work".

Again, this only applies to an extremely small segment of senders with poor
reputations.  It's 2007, most clients can handle this.

> something completely unrelated, so I may be missing something there).

No,  you don't whitelist the  IP.  You add the IP and the sending domain
from the resent bounce (the resent bounce has authenticated the domain) into
a database.  This database works just like SPF.  Let us assume that the
sender now emails a a third party.  This third party can look at the
sender's domain and sending IP.  The third party then accesses this new
database and is able to authenticate the sender.  The sender only had to
resend one bounce, and now the entire world can authenticate every future
email sent from the senders domain via that IP.

> MUA to handle HTML and render images within the client.

Clients will only need a one time update, and they don't even need that.
The bounce from Figure three is only sent to senders that despite
authentication are still suspicious, but yes - the client will need to be
able to display images.

It seems that it will send unwanted email to strangers.

Section 9

It also seems
> case of a non-compromised tagged address.

I used sub-addresses is completely unique  way.  A  non-compromised
sub-address will effectively guarantee successful delivery of ham.  I'm not
entirely sure what aspect of my use of sub-addresses you are concerned
about.

> of the descriptions if you're looking for broader feedback.

It uses the same principle as SPF (a database connecting domains to sending
MTAs) but yes, it is not literally SPF since only the administrators of the
sending domains generate the real SPF database.

You'll
> bulk email, such as mailing lists, as that's not clear from your

Legitamate bulk email senders who maintain good reputations will continue to
have their email delivered directly to the inbox.  This system will actually
enhance delivery of legitimate bulk email; current filters simply junk much
of the email from these senders, but my system will allow for their delivery
(see section 12 item 3 and the related info in that section to see how RIA
will perform in comparison to convention filtering).

Thank you for your feedback,

Michael

---

From: "Al Iverson" <[email-masked]>
Date: Sun, 16 Sep 2007 22:19:19 -0500

> Thank you for your feedback,

My feedback is that you should build it, see how it actually works for
you, convince others to try it. If you can drive mass adoption then
you've got something.

Regards,
Al Iverson

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
Remove "lists" from my email address to reach me faster and directly.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Sep 2007 20:25:56 -0700

Steve Atkins wrote:

> decade - it's got ...

Other than that, Mrs. Lincoln, how did you like...

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 17 Sep 2007 12:11:13 +0200

Michael Kaplan wrote:

> The core of this concept is that questionable unauthenticated email
> will be bounced

I hope you mean "rejected", unsolicited bounces are evil.  If whatever
you do is some kind of "receiver generated SPF database" I also hope
that folks like me, where all legit mails get a PASS, and anything
else (including traditional forwarder scenarios) gets an SPF FAIL,
don't need to worry about your concept.
  
But I'm far from confident that that's the case, there are dubious
statements on your page.  Example:

| A perfectly comprehensive SPF record would require every domain
| administrator in the world to constantly update their domain's
| SPF record; an impossible expectation.

As long as the IPs and/or domain names describing the "border" of an
alleged sender don't change the administrator has no reason to touch
her SPF sender policy.  

> Existing SPF cannot authenticate forwarded email.

To some degree it can, receivers are free to whitelist forwarders
based on a HELO PASS for the outgoing MTAs of trusted forwarders,
and forwarders are free to become redistributors, i.e rewrite the
MAIL FROM.

> overcome this other major flaw with SPF

JFTR, that's only the short story.  The long story is that this is
a major flaw in the "simplified" e-mail architecture, specifically
in RFC 1123 5.3.6(a), inherited by RFC 2821.  In the "original"
RFC 821 architecture each hop (including forwarders) had to modify
the MAIL FROM resulting in a literal concept of "return path".

Actually SPF offers to fix this major flaw in the SMTP architecture
without "return routes" (see RFC 821 for the technical details, or
the summary in an appendix of RFC 2821).

Traditional RFC 1123 5.3.6(a) forwarding is broken by design.  And
domain administrators publishing an SPF FAIL policy know that this
is the case, and accept that that their mail will be rejected by
receivers supporting SPF in traditional forwarding scenarios.  It's
the price for getting rid of tons of bogus bounces for forged mails.

And nobody's forced to pay this price until they actually need it,
but I digress.
  
 [RIA]
> Innocent third parties will be relatively unaffected by erroneous

If innocent third parties with an SPF PASS/FAIL policy are affected
your system is broken.  Many SPF participants can't add BATV to their
setup, or won't even if they could for various reasons.  

If innocent third parties without BATV or without SPF PASS/FAIL
policy are "relatively unaffected" they might have their own opinion
about this issue.  As an example I'd never allow Outlook Express to
send "auto-responses".  It's bad enough that I use this software at
the moment.

Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 17 Sep 2007 12:07:45 +0200

|A perfectly comprehensive SPF record would require every domain administrator in the world
| to constantly update their domain's SPF record; an impossible expectation.

As long as the IPs and/or domain names describing the "border" of an alleged sender don't
change the administrator has no reason to touch her SPF sender policy.  

To some degree it can, receivers are free to whitelist forwarders
based on a HELO PASS for the outgoing MTAs of trusted forwarders,
and forwarders are free to rewrite the MAIL FROM.

the MAIL FROM resulting a literal concept of "return path".

  
 [RIA]

Frank

---

From: "Michael Kaplan" <[email-masked]>
Date: Mon, 17 Sep 2007 11:52:35 -0400

On 9/17/07, Frank Ellermann <[email-masked]> wrote:
> I hope you mean "rejected", unsolicited bounces are evil.

Yes, in section 9  I summarize the Ironport data on the bounce problem, and
it is a real problem.
Sometimes legitimate email is unauthenticated; adopting a policy of
absolutely never sending a bounce in response to an unauthenticated email
will degrade the integrity of email.  Banning all such bounces solves one
problem and creates another.

Indiscriminate bounces are the real problem with bounces.  In section 9 I
demonstrate what would happen if 50% of the global email population used RIA
and 4% of incoming spam was bounced.  The conclusion is that the average
user will receive a 0.2% increase in 'spam' volume.
Some individuals/entities will suffer a DDoS attack as their domains are
heavily spoofed by spammers.  In this worse case scenario RIA will increase
their email volume by only 5% despite having 50% global participation in
RIA.

Again the real problem with bounces is indiscriminate bouncing, highly
selective bouncing is relatively inconsequential.  50% of the global
population would have near perfect protection from spam in exchange for only
a slight increase in erroneous bounces.

  If whatever
> don't need to worry about your concept.

Any email that gets an SPF FAIL will never be bounced.
You never send spammy email, and all of your email is already
authenticated.  You will never even be aware of the existence of RIA as your
emails will never be bounced.  You need never use a sub-address, or you can
use a deactivated sub-address - it really doesn't matter since your emails
are unambiguously ham so they will always directly reach the inbox.  Almost
all email sent by individuals is unambiguously ham; most individual senders
will remain completely unaffected by RIA.

> alleged sender don't change the administrator has no reason to touch

This is good; RIA will never block authenticated email from reputable
senders.  RIA will almost exclusively impact the less responsible senders
who do not authenticate and also get a poor rating via a statistical filter.

> and forwarders are free to become redistributors, i.e rewrite the

This is also good; email sent via trusted forwarders will be considered
authenticated and RIA will not obstruct it.  Some forwarders employ SRS, but
some don't.  Email sent without a sub-address via an untrusted forwarder
that does not employ SRS will get bounced... but only if a statistical
filter classifies the email as 'unsure'.

> setup, or won't even if they could for various reasons.

Bounces will not be sent to an SPF FAIL.  See section 9 as to the impact on
innocent third parties.

> send "auto-responses".  It's bad enough that I use this software at

If you (and 50% of the global email population) instituted RIA and
subsequently became almost completely spam free, could you then live with
the fact that non-participants in RIA and non-participants in BATV will
suffer an average of a 0.2% increase in spam volume?  Yes, a very small
number of individuals will suffer a 5% increase in erroneous bounce
traffic.  50% of the email population living spam free would be an
extraordinary thing; I for one would be willing to live with the guilt.

Thank you for you input,
Michael

---

From: "Peter Bowyer" <[email-masked]>
Date: Mon, 17 Sep 2007 16:57:09 +0100

> problem and creates another.

Your use of 'Yes' in your answer to Frank was clearly in the sense of
'No'. Unsolicited bounces are evil, and you're still proposing to send
them. This is bad. Why are you not talking about SMTP-time rejections,
which are not evil and don't suffer the same issues?

Peter

-- 
Peter Bowyer
Email: [email-masked]

---

From: "Michael Kaplan" <[email-masked]>
Date: Mon, 17 Sep 2007 12:26:49 -0400

> which are not evil and don't suffer the same issues?

I am concerned about forwarded email.  Once the Receiver Generated SPF
database is established then most of the unauthenticated ham will come via
forwarders who already accepted the original email.  I'm open to any
suggestions on how to work around this, otherwise I still argue that highly
selective bounces are only mildly evil.

If we quantify evilness then:  Massive quantities of spam >> small number of
misdirected/easily filtered by BATV bounces.

I'm arguing for the lesser of two evils, and I argue that my evil is much
much smaller than the evil of existing spam.

Michael

---

From: "David Nicol" <[email-masked]>
Date: Mon, 17 Sep 2007 12:08:40 -0500

> selective bounces are only mildly evil.

Quarantine (or soft-fail) and query the recipient.  Parse the headers in the
forwarded message; if a spf-good appears earlier, offer the addressee the
option of whitelisting the final relay. The addressee has signed up for the
protection, knowing there may be a touch of configuration.  Integrate with
reputation systems (and refer to documentation strongly suggesting using
a SPF-compliant RFC 821 "SRS" envelope instead of a simplified one) in
the 450 rejection) and statistical analysis in deciding how to dispose of
such messages.

-- 
"I will not tolerate continued noncompliance"
     -- Neelie Kroes

---

From: SM <[email-masked]>
Date: Mon, 17 Sep 2007 10:31:20 -0700

>this newly established database.

As this is a research group, it's good to see new proposals like 
yours.  Your proposal, like a few others, revolves around 
Challenge/Response.  Once we start meddling with bounces, we make 
that feature even more unreliable.

Near universal distribution of Auto-Resend software is not as easy as 
it sounds.  If you cannot get the administrators to update their 
systems, then you won't get hundred times more people upgrading their 
software.  The cost will be much more if you upgrade the client software.

CAPTCHA has been circumvented.  Getting users to a website to solve a 
CAPTCHA is not that difficult.  If spammers did not get more than an 
insignificant number of people to visit their website, they would not 
have been in business.  CAPTCHA also has usability issues.

A Single Universal Receiver Generated SPF Database is like having a 
single worldwide authority responsible for email.  This raises 
questions about control and cost.

I suggest that you don't underestimate the technical prowless of spammers.

Regards,
-sm

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 17 Sep 2007 14:12:18 -0400

> I suggest that you don't underestimate the technical prowless of spammers.

Freudian slip? ;-)

I can't help thinking that spammers will have a field day spamming 
themselves with forged, say, @hotmail.com, doing the captchas to 
"approve" bogus IPs, and then firehosing the world with what would now 
verify.  The Nigerian 419 hordes would have fun.

Frankly, also, much as I'm not fond of SPF, I'd object to having our SPF 
policy subverted to lend additional credibility to entities that aren't 
under _our_ control.

---

From: "Peter Bowyer" <[email-masked]>
Date: Mon, 17 Sep 2007 19:47:04 +0100

On 17/09/2007, Michael Kaplan <[email-masked]> wrote:
> > > On 9/17/07, Frank Ellermann <[email-masked] > wrote:
> > > > Michael Kaplan wrote:
> > > >

Not sure how that answers the question about Bounce vs Reject...it's
been asked twice now.

Peter

-- 
Peter Bowyer
Email: [email-masked]

---

From: SM <[email-masked]>
Date: Mon, 17 Sep 2007 12:13:32 -0700

>Freudian slip? ;-)

No. :-)  I was merely pointing out why every new measure introduced 
gets circumvented.

>"approve" bogus IPs, and then firehosing the world with what would 
>now verify.  The Nigerian 419 hordes would have fun.

Or they could push more authenticated mail through as they already 
control the user's computer.

Regards,
-sm

---

From: "Michael Kaplan" <[email-masked]>
Date: Mon, 17 Sep 2007 16:30:22 -0400

On 9/17/07, Michael Kaplan <[email-masked]> wrote:
> option of whitelisting the final relay.

It is good if addressees whitelisted the final relay; this would be good for
all mail systems, not just RIA.  If, however, mail comes via an forwarder
than does not have an established reputation then I would bounce the email.
If you don't then you will need to constantly expose the receiver to
unauthenticated spam; RIA is supposed to make the sending of unauthenticated
spam absolutely futile.  Receipt of the resent bounce will prove the
legitimacy of the original forwarding server so now the addressee can have
this forwarding server automatically whitelisted.

The addressee has signed up for the
> the 450 rejection) and statistical analysis in deciding how to dispose of

RIA will do all of this, but at the end of it a very small amount of
unauthenticated 'unsure' email will remain and require bouncing.

> that feature even more unreliable.

I argue that this is an excellent way to use bounces (even if a small number
are misdirected).  I'm not sure what "unreliable" refers to

> software.  The cost will be much more if you upgrade the client software.

Section 5.2 outlines how surprisingly simple it is to distribute Auto-Resend
to most of the population, and the last bullet point of section 11 details
how unnecessary Auto-Resend is.  A routine Windows Update patch would take
care of most of the Outlooks out there.
With passage of enough time people will inevitably upgrade their computers
and software, thus gradual near-perfect of Auto-Resend is inevitable.
Contrast this to the current SPF database; in 10 years it will still be
woefully incomplete.

> have been in business.

 Section 6.2 details how CAPTCHA, as used by RIA, cannot be circumvented.  A
CAPTCHA guarding against web page registrations needs to be a thousand times
more secure than a CAPTCHA that requires an non-spoofed email for every
attempt at solving it.

CAPTCHA also has usability issues.

If RIA got rid of the CAPTCHA altogether then it would still be a system
that would generate a near perfect SPF record and authenticate all
questionable email.  The purpose of the CAPTCHA is to challenge the
extremely small number of emails that are 'unsure' despite authentication
(see reference #1); again most of the unsure authenticated ham will come
from bulk senders or senders with spambot compromised systems.  The CAPTCHA,
directed at this small population of senders, is needed to make the sending
of spam completely futile.  The CAPTCHA is only tolerable as so few
legitamate senders will ever see it; answering the CAPTCHA will improve you
reputation and help get you off of the suspicious list so in the future your
emails won't bounce.

> questions about control and cost.

This database will be based on preexisting proposals for a shared universal
reputation system (Reference 13).

In section 7 I theorize a mechanism of spammer circumvention and how to
neutralize it.  If anyone else can think of how spammers can bypass this
system then please let me know.

Regards,

> verify.  The Nigerian 419 hordes would have fun.

I'm not sure what it is you are describing.  Hotmail addresses cannot be
spoofed as Hotmail has an SPF record.  How would spammers control email
accounts that are used by participants of RIA?  (Other than what I describe
in section 7).  The Receiver Generated SPF database would be created by the
information generated from trusted email accounts such as those held by AOL,
Earthlink, Verizon, corporate customers, established trusted users of
Hotmail and Gmail (someone who signed up for a webmail account 5 minutes ago
probably won't be considered a trusted webmail user), etc.  How is a 419
scammer going to corrupt the database (other than as described in section
7)?

> policy subverted to lend additional credibility to entities that aren't

This is not a policy; the Receiver Generated SPF database is a private
database generated by all willing participants of RIA.  I'd love to think
that every major email entity would participate.

Thank you,
Michael

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Sep 2007 16:41:25 -0400

> control the user's computer.

But if they did try to push more "authenticated" mail it becomes the
ISP or companies issue because SPF authenticates the domain, not the
user. In fact, the port 25 approach does have certain advantages in
terms of reputation and accountability. If this were to play out I
think we would see more "walled gardens"

---

From: SM <[email-masked]>
Date: Mon, 17 Sep 2007 14:45:21 -0700

At 13:30 17-09-2007, Michael Kaplan wrote:
>I argue that this is an excellent way to use bounces (even if a 
>small number are misdirected).  I'm not sure what "unreliable" refers to

More sites may block bounces or drop them in the bit bucket.

>Section 5.2 outlines how surprisingly simple it is to distribute 
>Auto-Resend to most of the population, and the last bullet point of 
>section 11 details how unnecessary Auto-Resend is.  A routine 
>Windows Update patch would take care of most of the Outlooks out there.

That's assuming that the operating system is still supported and 
installs the updates.  There are a lot of legacy systems out 
there.  I won't ask who is going to pay for all this.

Regards,
-sm

---

From: "Michael Kaplan" <[email-masked]>
Date: Mon, 17 Sep 2007 23:32:58 -0400

> More sites may block bounces or drop them in the bit bucket.

Section 9.3 calculates how RIA, when adopted by 50% of the global
population, will on average increase 'spam' sent to innocent users by 0.2%.
Unlike with real spam BATV can perfectly block this 0.2% increase in spam
received.  I doubt that RIA will be the straw that breaks the back of the
bounce system.

> there.  I won't ask who is going to pay for all this.

Perfect adoption of Auto-Resend is impossible; fortunately it is not
needed.  Auto-Resend only enhances transparency.  Remember, if your email
domain (your domain doesn't have an SPF record) uses a single MTA then only
a single person using that domain will need to manually resend a single
bounce; every future non-forwarded email sent by anyone in that domain will
be authenticated.  Auto-Resend is a good feature, but RIA will remain almost
completely invisible to users even without Auto-Resend.

Who will pay for it?  I expect that the client and server software
developers will take it upon themselves to incorporate Auto-Resend as a
routine feature.  It is a one-time software upgrade.  It is not like a
statistical filter that requires constant maintenance.

Michael

---

From: SM <[email-masked]>
Date: Mon, 17 Sep 2007 22:28:39 -0700

At 20:32 17-09-2007, Michael Kaplan wrote:
>population, will on average increase 'spam' sent to innocent users 
>by 0.2%.  Unlike with real spam BATV can perfectly block this 0.2% 
>increase in spam received.  I doubt that RIA will be the straw that 
>breaks the back of the bounce system.

Your proposal mentions bouncing "difficult to classify email".  It 
may not be the straw that breaks the system but it may prompt the 
adoption of measures to block that type of email.

>developers will take it upon themselves to incorporate Auto-Resend 
>as a routine feature.  It is a one-time software upgrade.  It is not 
>like a statistical filter that requires constant maintenance.

The problem with every new proposal that is tabled is the cost 
involved and deployment factors.  One may see it as a one-time 
upgrade but it's non-trivial to implement because it involves either 
updating the MTA or the MUA.  Software developers are usually market 
driven especially when it comes to MUAs.  If they implement your 
proposal, it will only be available in new versions of the software.

I suggest that you implement the system you propose and publish the results.

Regards,
-sm