On 4/8/22 5:55 PM, None wrote:
> Indeed, looks like that. Even error codes about the amount of recipients
> being to high are not directly relayed back to the sender.
It depends on what "amount of recipients being too high" means. It
could be too many recipients for the given message, which I would expect
to cause an immediate permanent 5xx failure. Or it could be "we've seen
too many messages / different recipients from this sending server,
please try again later." which is akin to grey listing and shouldn't
cause an error.
> One would think that such required 'manual' alteration would be notified
> immediately. But I will try a few others.
It depends on what it is. There's a lot of subtlety to it.
> From my experience I can not really conclude people are not reading the
> error messages.
My experience is that people see /something/ -- it doesn't matter what
it is -- that is not the positive / affirmative result they are used to,
and freeze up or glaze over or otherwise fail to make sense of it.
Years ago I created a text message for a log in script that said:
--8<--
Call the help desk at 7220 and tell them "My computer says it needs to
be scanned." -- This message will no longer pop up after your computer
has been scanned.
-->8--
Once a month I'd have someone that would stop me while I was out working
on computers saying something like "my computer has this message that
pops up". I'd see what it was and ask them to read it to me. They
would read it without processing it and then ask "what do I need to do".
To which I'd tell them to read it again for the answer to that very
question. We'd go back and forth between one and three times. Usually
it ended with them saying "so I've been putting up with this message for
many months when all I needed to do was to call the help desk and say
one thing?!?!?!" to which I'd say "yes".
Sometimes they'd ask me to fix things while I was there. I'd tell them
that I can't, and that they would need to follow the directions on their
screen.
You can lead a horse to water, but you can't make it drink. People have
to want to help themselves.
> Even if, I can't be blamed if someone else is failing to read something.
Oh, trust me, you can be blamed.
I ran into all sorts of excuses as to why people didn't read the
message. "It's a computer error...." or "errors are for technicians..."
or the likes.
> Next time they read it, when they want to get thru.
Yep.
"Tar is cowardly refusing to create an empty archive."
The reasoning for the error is staring you in the face. But you have to
be able to see past the trees to appreciate the forest.
> Yes that is a really weird concept "I can contact you, but you are not
> allowed to contact me". I can't wait for the legislation where the
> noreply@... stuff is being banned.
Banning it won't be any more effective than banning spam / viruses /
other computer crime.
I have always believed that each and every noreply@ bull shit is a
missed opportunity. It's relatively easy to encode all sorts of
information about what sent the message using VERP. It's fairly easy to
use a legitimate From: header, VERP like or otherwise. It's
ridiculously simple stupid to use a Reply-To: header to re-direct the
inevitable reply to somewhere useful, even if it's just an info@ type
positional address that a robot looks at before a human does.
Aside: You can even do something to indicate to the robot that this
message is from someone that has received a message from the company.
If you're smart about it, you can encode information about the message
that the reply is from, thus who the message was sent to that is being
replied to that generated the message that the robot is processing.
Maybe it's just me, but I don't think this is hard by any stretch of the
imagination.
noreply@ bull shit is a wasted opportunity.
> Companies/users that send from spamming networks, I offer ip
> whitelisting (when they get dedicated ip), email address (envelope from)
> white listing, and now a link in a dsn.
> I think that is quite a nice service towards people being cheap sending
> via third rate services.
I'll give you kudos to the link in the DSN. Props if the link encodes
details to partially fill out a form. ;-)
Aside: Be careful with the link. Don't obfuscate things. Let people
see what is being sent. It's good will or anti bad will. Also,
authenticate what is sent & comes in so that someone can't get up to
mischief.