llTargetedEmail()

[Sayrah Parx]

It's great if you have a way to edit others' objects and have no other way to contact them.  It's a great way to be sent offline messages and notices, after the offline message and notice cap was reduced 40% from 25 to 15.  For most groups, it would be great to have the option of notices only being sent to e-mail when not logged in for that particular group, in the same way there are options for receiving chat and notices for each group.  If sending e-mails is better for the SL infrastructure than storing offline messages and notices for the next login, then this seems like a great first step.  I hope we can have that option for group notices sometime soon, because after the 40% cap reduction I've had to turn off notices completely in most groups that get sent notices frequently.

[Wulfie Reanimator]

1 hour ago, Sayrah Parx said:

It's great if you have a way to edit others' objects and have no other way to contact them.

This is a very niche use-case, and still effectively a violation of privacy. What if I don't want you to contact me? Imagine that some annoyed customer (or ex/frenemy) starts spamming my personal email because I haven't responded to their questions, either because I haven't had the time yet, or I simply don't want to. I don't know if blocking a resident even affects llEmail.

Edit: Blocking a resident does not prevent emails from objects they own.

1 hour ago, Sayrah Parx said:

It's a great way to be sent offline messages and notices, after the offline message and notice cap was reduced 40% from 25 to 15. ... If sending e-mails is better for the SL infrastructure than storing offline messages and notices for the next login, then this seems like a great first step.

You can already direct offline IMs to your email, and there is no limit to it. The cap only applies to the amount of messages shown to you in the viewer after you log in. This is not the first step and it's not a particularly good one either.

1 hour ago, Sayrah Parx said:

For most groups, it would be great to have the option of notices only being sent to e-mail when not logged in for that particular group, in the same way there are options for receiving chat and notices for each group.

This should be an account feature just like offline IMs, not an LSL feature.

Edited April 1, 2020 by Wulfie Reanimator

[Mollymews]

6 hours ago, Oz Linden said:

We plan to modify/replace the ROOT_CREATOR function to be one less useful for spamming... stay tuned

oooh!

whenever I read something like this my brains go into guessing mode

my guesses. CREATION_DATE ? and OBJECT_CREATOR and SCRIPT_CREATOR must be the same ?

also I keep trying to guess what completely new things might Linden come up with to include in the Premium Plus that might tempt people to take it up. A completely new thing would be mollymews.resident@secondlife.com, which can be only accessed from an inworld object with llTargetedEmail  ?

 

 

[Sayrah Parx]

It's good to see them trying.  I recently had a friend request sent to me get dropped due to the cap and only found out about it from the offline e-mail.  Group invites may also get capped and dropped.  There's no way to accept either of those from the offline e-mails.  The idea for group notices was to have it part of group settings and not from a script.  Many of us have already posted our criticism of llTargetedEmail.  But it's also good to see a new focus on using e-mail for messages, because communication is so important to the economy.  Anything that can reduce reliance on the capped stored message system is a good thing.  They said that the part that could be abused will no longer be functional.  So if someone doesn't have a use case for it, its existence is not going to hurt them any more than something else almost no one uses like llOpenRemoteDataChannel.

[Aishagain]

@Sayrah Parx: 

OK I accept that there might be a marginal case for this script function that is not a griefing exploit.  However there seems to me to be a disconnect between exploits that LL do NOT want, which can cause rollbacks and the like and one that for their own reasons they DO like, in which case they ignore our criticism and warnings of abuse.

Wulfie stated most of the misgivings that I continue to have in his post above.

[Extrude Ragu]

Judging by the wiki they deprecated sending to the creator.

[Lucia Nightfire]

3 hours ago, Extrude Ragu said:

Judging by the wiki they deprecated sending to the creator.

It's not deprecated yet. It might be next week, though.

The only other-than-owner parameter I can see being "slightly" useful would be TARGETED_EMAIL_SCRIPT_COMPILER which would only send emails to the person that compiled/saved the script, which would be what "creators" would want/need/prefer in an end-user environment.

Again, I say slightly as the only real benefit is dynamic email address pointing without the need to access a remote db to get the current email address.

[animats]

On 4/1/2020 at 8:31 AM, Oz Linden said:

We plan to modify/replace the ROOT_CREATOR function to be one less useful for spamming... stay tuned

I see it's now marked as "deprecated do not use" in the wiki. I'd suggest keeping it, but only for when an object is sending to its own creator. It's useful for objects that want to phone home with debug info.

(SL doesn't have good logging facilities for debugging. It's nice to see something added in this area.)

[Qie Niangao]

37 minutes ago, animats said:

I see it's now marked as "deprecated do not use" in the wiki. I'd suggest keeping it, but only for when an object is sending to its own creator. It's useful for objects that want to phone home with debug info.

(SL doesn't have good logging facilities for debugging. It's nice to see something added in this area.)

But I'm not following something: if it's still okay "when an object is sending to its own creator" what's to stop subsequent owners of mod-perm objects from inserting a script that calls this function and spams that creator who never planned on getting such messages? It doesn't actually help much to make it the script creator for those who've released full-perm scripts into the world.

For somebody debugging their own code from objects owned by themselves, the _OBJECT_OWNER flag would suffice; from objects distributed to others, just plain ol' llEmail() works fine except it can't directly support change of email address, if that's really a need.

[Zi Ree]

I wonder why it is marked as "Deprecated" when the function hasn't even been released yet. They could just take it out completely without even mentioning it at all.

[Mollymews]

8 hours ago, Zi Ree said:

I wonder why it is marked as "Deprecated" when the function hasn't even been released yet. They could just take it out completely without even mentioning it at all.

agree

i think tho that the proposed functionality is coming again in another form

[Nova Convair]

So it's an - easy to implement - phone home function. One could think the world already has enough phone home things.
And nobody got the idea that it can be used for spam?

However - I can easily block object emails if I need to do so and if I really have an object that sends me emails I will add a prefix to the subject. So i can easily whitelist the messages of my own scripts. llTargetedEmail is no problem for me and spamming is futile.

It's interesting that the 1st thing you do when a new function is implemented to see how you can protect yourself. 😎

[Kyrah Abattoir]

1 minute ago, Nova Convair said:

So it's an - easy to implement - phone home function. One could think the world already has enough phone home things.
And nobody got the idea that it can be used for spam?

However - I can easily block object emails if I need to do so and if I really have an object that sends me emails I will add a prefix to the subject. So i can easily whitelist the messages of my own scripts. llTargetedEmail is no problem for me and spamming is futile.

It's interesting that the 1st thing you do when a new function is implemented to see how you can protect yourself. 😎

Call it experience.

For a lot of us this isn't our first "adventure" with Linden Lab.

[Wulfie Reanimator]

1 hour ago, Nova Convair said:

However - I can easily block object emails if I need to do so and if I really have an object that sends me emails I will add a prefix to the subject. So i can easily whitelist the messages of my own scripts. llTargetedEmail is no problem for me and spamming is futile.

Just because it's easy to fix doesn't change the fact that you would have to fix a problem that didn't exist until now. It's dumb design even if it doesn't necessarily affect you (or me).

And just to clarify, I don't have a problem with the owner part. At least if the spam gets too heavy, the owner can remove the object.

Edited April 5, 2020 by Wulfie Reanimator

[Coffee Pancake]

Did anybody ask for this ?

[ItHadToComeToThis]

This is going up there with llGetMoonRotation.

Why are we being given pointless and unneeded functions and being constantly denied useful things such as custom libraries, native switch statements, conditional operators....or....perhaps finally giving us those grid wide experiences promised all those years ago.

Edited April 7, 2020 by ItHadToComeToThis

[Wulfie Reanimator]

1 hour ago, ItHadToComeToThis said:

This is going up there with llGetMoonRotation.

Why are we being given pointless and unneeded functions and being constantly denied useful things such as custom libraries, native switch statements, conditional operators....or....perhaps finally giving us those grid wide experiences promised all those years ago.

I don't think those are a very good comparison. Those are entire features that would almost definitely take more work than a single function.

llGetMoonRotation at least has legitimate uses (niche or not) with no harmful side-effects.

But what about other things like llCastBox or llCastCircle (volume-based raycasting), llDamage without requiring a collision that instantly kills the object, llDamage with negative values (healing), objects being able to detect LL damage (even if they stay unkillable), being able to iterate children of a linkset the script isn't in (eg. you have a root key but need a specific child), etc...

Edited April 7, 2020 by Wulfie Reanimator