llTargetedEmail()

[KT Kingsley]

Not sure I like the sound of this.

https://releasenotes.secondlife.com/simulator/2020-03-27T23:25:44.539377.html

[Ruthven Ravenhurst]

Didn't see it on the page, any details anywhere that's different about just llEmail?

[KT Kingsley]

Oh. Wednesday.

[KT Kingsley]

 But...

Quote

Second Life RC:

https://releasenotes.secondlife.com/simulator/2020-03-27T23:25:44.539377.html

More details coming soon!
Scheduled Wednesday 2020-04-01 07:00-10:30 PST (no joke!)

 

[Rider Linden]

It would appear that I did not correctly link the function up in the wiki (I will do so today.) 

llTargetEmail() is a convenience function that will send an email to certain "well known" agents if they have a verified email address associated with their profile. The two targets defined at this time are:

• TARGETED_EMAIL_ROOT_CREATOR
  Sends the email message to the creator of the root object in the linkset.
• TARGETED_EMAIL_OBJECT_OWNER
  Sends the email message to the owner of the object or linkset.

More information can be found on the wiki:

http://wiki.secondlife.com/wiki/LlTargetedEmail

 

[Zi Ree]

What if someone gets hold of a full perm object I made and uses that to spam my email?

[panterapolnocy]

Indeed. Valid question. Example then. If someone make 10 alts, then get an item created by me that is modifiable (from Marketplace for example) and drop a script with TARGETED_EMAIL_ROOT_CREATOR in it that sends mails in loop... Even with 20 seconds delay that's 3 emails per minute. 180 emails per hour. Per user. With 10 alts it's almost 2000 messages per hour on my mailbox. Because owner of said alts can spam my mailbox via Lab's servers without even knowing my SL-only email address for getting emails from grid.

I know I would be slightly annoyed after waking up at the morning and checking my Thunderbird. There is one interesting use for this function, however, at least for me; Leave TARGETED_EMAIL_OBJECT_OWNER only, cut out creator part and make delay lower than normal llEmal() - so it still would be useful for some purposes (no need to hardcode own email in the code, would still work if email would change and it would get changed in SL's profile etc) and would also cause script to recover faster from sleep.

 

Edited March 31, 2020 by panterapolnocy

[Kimberly Covfefe]

I've already opted in to receive messages from agents I have chosen, via group notice and scripted object subscriptions, with offline messages sent to my email address. Now, it seems that anyone who owns a modifiable prim I have created can spam me with an email every 20 seconds, simply because I have created a prim in the past and have offered a recipient permission to modify the prim. Worse yet, I see no opt-out options. All other messages generated by SL residents and forwarded by LL to my email are on the opt-in basis I mentioned above. This is NOT an opt-in feature, and with no opt-out I can only see the potential for abuse, and I cannot see a good reason for the feature.

[KT Kingsley]

We can only hope that the source email address is distinctive enough that it can be blacklisted in our email services without also blacklisting the stuff from LL and SL that we actually want.

I can't help thinking that this won't help the Lab's attempt to shed its reputation as a spamming service, which led to the introduction of verified email addresses.

Edited March 31, 2020 by KT Kingsley

[Lucia Nightfire]

There was no discussion of this fast-tracked function with the community in any UG, no public feature request jira, no public testing and no public awareness until today.

Typical SOP...

[Sayrah Parx]

30 minutes ago, Lucia Nightfire said:

There was no discussion of this fast-tracked function with the community in any UG, no public feature request jira, no public testing and no public awareness until today.

Typical SOP...

It's very strange because it's something I thought would be great for a long time, but it doesn't seem to be planned well at all.  As a general concept, it's something we've needed for a long time to be able to reduce offline notices and IMs, but the implementation looks terrible and practically useless for most situations.  Now that we're finally aware of the attempt to make something like this possible, I imagine that any feature request would be met with "we're not going to do _____ to make it actually worthwhile because we've painted ourselves into a corner with how we've already implemented it."  But the good thing is that they picked one of the worst possible names for the function, so they could still make a better version with a new function name.

[Wulfie Reanimator]

6 hours ago, Rider Linden said:

It would appear that I did not correctly link the function up in the wiki (I will do so today.) 

llTargetEmail() is a convenience function that will send an email to certain "well known" agents if they have a verified email address associated with their profile. The two targets defined at this time are:

• TARGETED_EMAIL_ROOT_CREATOR
  Sends the email message to the creator of the root object in the linkset.
• TARGETED_EMAIL_OBJECT_OWNER
  Sends the email message to the owner of the object or linkset.

More information can be found on the wiki:

http://wiki.secondlife.com/wiki/LlTargetedEmail

 

I'm not at risk of being targeted, but even I'm concerned by this function being made available. What safeguards do you have against spamming? This function seems like a legitimately bad idea that affects more than just the creator/owner. This is the kind of function that people can use to justify making everything no-mod, further stifling the creativity of users.

[Nova Convair]

The messages from SL are easy to filter by sender and subject, so I assume it will be no problem to filter this type too. We'll see.

Problem solved then.

But I'd like to know who needs this function and for what? (besides spammers)

[Aishagain]

I've looked at this until my eyes bleed and I cannot, for the life of me, see a valid need for such a function, though the previous posters have delineated several seriously griefing uses.  This has all the hallmarks of a Friday afternoon "bright idea" that is being implemented without serious consideration for its uses and/or misuses.

LL would never introduce such a function without giving careful consideration to its application, of course...would they? 🤯

Edited March 31, 2020 by Aishagain

[Rolig Loon]

37 minutes ago, Nova Convair said:

But I'd like to know who needs this function and for what? (besides spammers)

I agree.  This sounds like a function with dubious value and a very frustrating downside. I don't know how it got through internal review.

[Mollymews]

i get where TARGETED_EMAIL_ROOT_CREATOR could be useful, like to be able to send a support request to the creator who sold me the stuff, but given the number of full permissions prims already out in the wild then for all the reasons others have given above then I would drop it. Is not worth the hassle

the TARGETED_EMAIL_OBJECT_OWNER is ok, as could be quite useful for inworld shops and rentals. Given that the owner can throttle  the number of emails from a person, and blacklist if necessary, from within the script

altho given that with llEmail we can do this latter already then am not seeing the point really

[Ardy Lay]

Reading this makes me hope I am not "well known".

[Toothless Draegonne]

I can see some use, as in being able to email someone without giving out an actual email address. As for abuse, well, if it can be used it will be abused. I imagine it'll get dealt with in the same way as usual. You'll see the usual suspects playing with it until they get bored and enough alts get banned, then it'll just become part of the LSL toolset.

So long as emails coming from it are easily identifiable, they can be dealt with the same way as every other spam source if you're targetted. And honestly, if you've set your account up to receive IMs as emails while offline (which I guess a lot of creators already do), you should be worried about that far more than this function. The flood limit for llInstantMessage is much more spamworthy than llEmail, and to my knowledge isn't affected by the SVC-23 bug that makes llEmail next to useless anyway (and will probably severely curtail any use for this new variation).

As for people using this as an excuse to release stuff as no-mod: They don't need an excuse. And you have the choice to just not buy or use their stuff. Pick someone who's more modder-friendly. There's plenty of those around!

[Wulfie Reanimator]

3 hours ago, Toothless Draegonne said:

So long as emails coming from it are easily identifiable, they can be dealt with the same way as every other spam source if you're targetted. And honestly, if you've set your account up to receive IMs as emails while offline (which I guess a lot of creators already do), you should be worried about that far more than this function. The flood limit for llInstantMessage is much more spamworthy than llEmail, and to my knowledge isn't affected by the SVC-23 bug that makes llEmail next to useless anyway (and will probably severely curtail any use for this new variation).

First of all, SVC-23 isn't relevant because it affects objects receiving email.

That said, the comparison to llInstantMessage (or offline messages in general) is not valid.

Offline IMs are grouped together whether they come from avatars or llInstantMessage. Here's what a 36-message spam looks like:

integer count;

default
{
    touch_start(integer total_number)
    {
        ++count;
        llInstantMessage(llGetOwner(), "test " + (string)count);
        llSetText((string)count, <1,1,1>, 1);
    }
}

That grouped email obviously doesn't arrive instantly either. However, if I use llEmail, the email does arrive immediately as its own email per function call (note the timestamp):

default
{
    touch_start(integer total_number)
    {
        llMessageLinked(LINK_SET, 0, "", "");
    }
}

default
{
    link_message(integer sender_num, integer num, string str, key id)
    {
        llEmail("email@email.com", (string)llGetLinkNumber(), "MESSAGE");
    }
}

llEmail is fine because you can't send stuff to my personal address (which I have tied to my SL account) because you don't know what my email address is. With llTargetedEmail, you don't need to know.

3 hours ago, Toothless Draegonne said:

I can see some use, as in being able to email someone without giving out an actual email address.

Any kind of  "contact owner/creator" functionality was already possible with llEmail. You could either hardcode your business email into the script (not limiting yourself to whatever email you have registered to your account), or you could include some very simple code to make the address configurable. The downsides of this function seem much greater than what it provides over llEmail.

Whether or not the spam can be filtered out in your email service is besides the point, and in some cases filtering them will be impossible because you might be receiving legitimate emails from objects. I have no reason to believe the sender address will be any different from "key@lsl.secondlife.com" and if that's the case, it can become difficult to filter only the spam.

Edited April 1, 2020 by Wulfie Reanimator

[Lucia Nightfire]

There was some brief discussion in the server UG about it, albeit not much from LL as they didn't seem to want to talk about it, a disturbing trend that started recently.

 

[mikka Luik]

I already happily use llEmail - when I want to and it is trivial and even to 'well known email addresses' ie mine and a few who asked to be notified (some of my stuff has the option for the owner to enter their own. No idea if any use it but still). Not even getting into the 'nomod' discussion - a lot of my stuff is full perm building kits.

Echo the 'friday bright idea' theme - who came up with this in the first place and why did they not think of at least having a global opt-out?  (yeah can see who posted the wiki entry)

[Oz Linden]

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

[Zi Ree]

1 minute ago, Oz Linden said:

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

Glad to hear you're reconsidering! But why do we need this function at all? Apart from reacting to changed mail addresses, I can't see any real use for it. Can you share a use case I am missing?

[animats]

I'm a little surprised to see that as a new feature. It's useful to me, because I can use it to let my NPCs send longer debug logs to their owner. (IMs have a shorter size limit.) But it seems strange that this got enough priority to be implemented.

I'd like to have the 20 second blocking delay implemented as a delay only if you make a call within 20 seconds after the last call.  If it applies to the first call, you need to add an extra script and inter-script messages to send trouble reports without blocking the sending process. If it applies only to calls within 20 seconds of the first one, scripts can check when they last sent and avoid another send.

[Aishagain]

@Oz Linden

You simply are not getting the message.  This function is neither wanted nor needed.  It is utterly redundant and a waste of somebody's valuable time.

Edited April 1, 2020 by Aishagain