Does instant feedback work (anymore)?

[shelleycat1]

I am retired now, and was never that involved in email. But batching up the feedback comments, and doing a count when sending them, seems a very effective way of stopping spam.

 

[qidniz]

Yep, received both about 4 hours ago.

Thank you!

My tests also finally worked, in a way. My test private feedback message to my inactive account on Yahoo is still MIA, whereas the message from the inactive account to my active account finally arrived, more than two days late - and curiously, hours after a later second test in that direction using the link at the end of a story page. This inversion of temporal order further suggests there is a review process before messages are emailed.

 

[BeechLeaf]

Looks like typical Literotica 'batching' (or whatever it is), can't be explained by any easy concept of queues or backlogs, just things accumulate and then at some point they happen. At one point I had a comment I'd submitted two days ago, another the previous day, and another that morning, and they all appeared in the same batch that day.

It has been suggested e-mails are scanned for spam, but who knows? How would it be done, and how would it explain the delays? I picture the software here as more like mini-golf or pinball.

 

[qidniz]

It has been suggested e-mails are scanned for spam, but who knows? How would it be done, and how would it explain the delays?

It would explain the delays in terms of the curators getting a Round Tuit, depending on their priorities. Perhaps comments on stories perhaps come before private feedback, and both kinds could be behind more pressing concerns such approving new stories.

Spam detection may not be much more than automated search for off-site URLs. The incidence is likely to be low inasmuch as there are tests against automated submission.

 

[MillieDynamite]

Even back when I was on here in 2016, feedback email was closer to snail mail than quick. When I came back in 2021, it was slow as molasses.

 

[Britva415]

Please name at least one program or system that batched the "sending of email messages" - understood to mean introducing messages into the mail delivery system from some other storage system.

The batching-emails feature is also an option which to this day remains a configurable option, if not an out-of-the-box default, of a variety of off-the-shelf packages today. My experience mostly comes from several different custom enterprise business applications developed and operated during the period at three different, unrelated companies.

I’m sure you’ll just deflect this by saying our team must have royally sucked. Great - now you have two examples of applications which did/do something that doesn’t make sense to you. And I agree - in 2026 it doesn’t make sense, but here we are *gestures ambiently*.

one would pass messages as expeditiously as possible to the mail delivery system, which would have had a far better crash safety record than any home grown alternative

We aren’t talking about a home grown alternative. We’re talking about a system which USES a separate purpose-dedicated “mail delivery system” (the email server I referenced) to deliver the mail. Anything but homegrown.. But getting the messages to the mail server for the mail sever to do the delivering-the-mail job is still a job the upstream application has to perform. If it’s lower priority than other performance-sensitive jobs that application has to do, then, mail can be deprioritized temporally and optimized performance-wise by batching the messages.

It isn’t the email server that’s doing the batching. It’s the composition of messages and exporting them out of the upstream application so that the HIGHLY performant (we’re in agreement) purpose built email server can do that last-mile job of sending an email.

It isn’t mail until it is mail. Before that, an application which was built to do different jobs other than delivering emails - and is not doing the job of delivering emails - might have performance optimization concerns which make processing these messages and sending them to the outbound email server a less-than-realtime priority,

 

[redgarters]

I've had 3 seperate feedback emails to my Gmail account in the last few days. Seems to be working fine.

 

[qidniz]

The batching-emails feature is also an option which to this day remains a configurable option, if not an out-of-the-box default, of a variety of off-the-shelf packages today.

Please name one, so I can look it up.

But getting the messages to the mail server for the mail sever to do the delivering-the-mail job is still a job the upstream application has to perform.

In the simplest case, open a TCP connection to localhost+port 25 and talk SMTP, A thousand local mail clients can do that for you taking just your message as input. This has been bog standard technique since the 80s. No batching needed, or necessary. It's just a waste of time and resources (and maybe the consultant fees to maintain white elephants.)

might have performance optimization concerns

That sounds like handwaving. I've been a systems architect and developer, and I have no idea what you're talking about. Briefly, if you need to pre-process messages, do so. (E.g., add a disclaimer or other boilerplate.) But at the point you have a message processed - i.e. ready to send - you send it off. You don't batch it.

[This whole discussion was based on the assumption that a message submission was basically ready to be sent. I now believe that is a misapprehension - all messages are reviewed, at varying levels of lower priority.]

I gave you the chance to give specifics, but you weaved and dodged. I'm done with this conversation. Thanks.

 

[Britva415]

A thousand local mail clients can do that for you taking just your message as input

Right. So the mail client is a separate application from the one we're talking about. Glad we're clear on that.

But at the point you have a message processed - i.e. ready to send - you send it off. You don't batch it.

No, you batch the other part of that process you just described. You don't get it "ready to send" for free. That can take way more CPU cycles than just sending the message. However - TCP/SMTP can also introduce latency into a process that can't afford it. That's another reason to batch it: You schedule this job for a time when the application doesn't need all its ticks for whatever its real job is. So even if it isn't computationally crippling, it can be temporally crippling and crash an application, if it's already performing marginally.

 

[TheLobster]

Every AH thread attempts to expand until it is about email. Those that cannot expand are replaced by ones which can.

— James Zawinski (disputed)

 

[qidniz]

(disputed)

I wonder what Jamie might have said about Lit.

Some authors, when confronted with a problem, think "I know, I'll post on AH". Now they have two problems.

 

[TheExperimentalist]

Every AH thread attempts to expand until it is about email. Those that cannot expand are replaced by ones which can.

— James Zawinski (disputed)

Definitely disputed. The word "email" in there is actually a misquote. The real quote instead mentions AI.