I'm really interested in seeing how you explain to a user how to turn on
"restricted mode" so they can get emails from their Aunt Sally regarding
next
week's family reunion picnic - and have them actually understand it.
You also get to explain to the user how to tactfully apologize to Aunt
Sally
for not being at last week's reunion because they weren't expecting the
mail to
be from Sally, but from her sister Susan, so Sally wasn't whitelisted.
Remember - from the user's point of view, your email software made them
miss
an important mail.
"Restricted Mode" isn't the default mode. A user have to turn it on by
clicking a button. A user will get a warning message like this when they
click the "Enable Restricted Mode" button.
Caution:
You are about to enter a sensitive zone.
“Restricted Mode” is intended for the boxes that deals with only
conversational mails.
So offload all website related mails to the Domboxes before you enable
this mode.
When the Restricted Mode is ON, we will send a challenge mail to the
Sender if the
sender is not found in your “Address Book”.
Real users can respond to those challenges. e.g. CAPTCHA. But automated
and bulk
mailers cannot. So their mails never gonna reach your inbox when the box
is Restricted.
Do you understand what you are signing up for?
(a) Yes, I know what I’m doing
(b) No, Get me out of here.
So if the "restricted mode" not enabled, john(_at_)example(_dot_)com can
receive mails
from Aunt Sally, Sister Susan and Uncle Fred without any issues just like
the current mail system.
Aunt Sally, Sister Susan and Uncle Fred gonna send their mails from a valid
mailbox. The whitelist part is necessary only if they are gonna send their
mails in an abnormal manner. In other words, the whitelist is necessary
only for "Unverified Strangers".
C/R mechanism is optional too. Without C/R, the system gonna work just like
the current mail system with spam filter, except mails only from "verified
strangers" are allowed.
Bonus points for explaining to the user that if Sally's husband Uncle
Fred does
a "reply all" to that mail, Fred is going to get a C/R response from your
user
and your user will probably never actually see Fred's reply. Oh, and your
user
had whitelisted Fred's *old* address, but didn't know Fred had a *new*
address?
Yeah, you can apologize to the user for that problem too....
We have method like "Intro via Mutual contact" and "Chain of Trust" to
overcome this issue. I have explained that in my paper
<https://www.dombox.org/dombox.pdf> on page 217 with illustration.
Double bonus points for explaining how you prevent the spammers from
automating
the C/R response using procmail or similar.
Since we accept mails only from "verified strangers" a spammer need a valid
domain to send out spam. The means, the mail is REALLY coming from the said
domain since the domain is either whitelisted the IP address or mail
received from one of their MX servers. So all spamming domains will be
considered as "verified spammers". We have a blacklist for "verified
spammers". We also check the "domain registration date" to rate limit
mails.
Triple bonus points for explaining how this scales, paying particular
attention
to help desk issues regarding "lost" emails because a user forgot to enable
restricted mode.
You misunderstood here. If the user forgot to enable "restricted mode", the
system will accept all mails.
I suggest you look at the Received: lines on your copy of this e-mail, and
for each step,
figure out what the RFC821 MAIL FROM probably was, the RFC822 From: (which
you don't see until you've accepted the DATA step), and what checking the
MX and SPF
entries would have shown for each step along the way.
I did cover the mailing list aspect in page 265 of my white paper.
In a mailing list, there are usually thousands of subscribers like you.
There will be an
address for posting the message.
Let’s say, politics(_at_)listserver(_dot_)com is the mailing list post
address. When
you post a message, listserver.com forwards the message to all the
subscribers.
For example, when the user Giri post a message, the message would look
like this when
viewed by others.
Envelope From: politics(_at_)listserver(_dot_)com
Message From: giri(_at_)dombox(_dot_)org
The point here is that the “Message From” domain can be any of those 332
million domains.
But “Envelope From” domain is gonna be listserver.com
On Wed, Sep 25, 2019 at 11:57 PM Valdis Klētnieks
<valdis(_dot_)kletnieks(_at_)vt(_dot_)(_dot_)edu>
wrote:
On Wed, 25 Sep 2019 15:06:33 +0530, Viruthagiri Thirumavalavan said:
By default, john(_at_)example(_dot_)com is a generic mail address. It can
accept
mails
from both human and websites. A user have to enable a setting called
"Restricted Mode" to instruct the system that it's a human-to-human mail
I'm really interested in seeing how you explain to a user how to turn on
"restricted mode" so they can get emails from their Aunt Sally regarding
next
week's family reunion picnic - and have them actually understand it.
You also get to explain to the user how to tactfully apologize to Aunt
Sally
for not being at last week's reunion because they weren't expecting the
mail to
be from Sally, but from her sister Susan, so Sally wasn't whitelisted.
Remember - from the user's point of view, your email software made them
miss
an important mail.
Bonus points for explaining to the user that if Sally's husband Uncle Fred
does
a "reply all" to that mail, Fred is going to get a C/R response from your
user
and your user will probably never actually see Fred's reply. Oh, and your
user
had whitelisted Fred's *old* address, but didn't know Fred had a *new*
address?
Yeah, you can apologize to the user for that problem too....
Double bonus points for explaining how you prevent the spammers from
automating
the C/R response using procmail or similar.
Triple bonus points for explaining how this scales, paying particular
attention
to help desk issues regarding "lost" emails because a user forgot to enable
restricted mode.
address. We heavily rely on MX record instead of SPF record to detect
mail
genuinity in human-to-human mails.
So... instead of looking at a DNS record that tells you where legitimate
emall
should be coming from, you're going to look at a record that is almost
guaranteed
to not point at a legitimate source for the email.
Yeah, that's going to work *really* well.
I suggest you look at the Received: lines on your copy of this e-mail, and
for each step,
figure out what the RFC821 MAIL FROM probably was, the RFC822 From: (which
you don't see until you've accepted the DATA step), and what checking the
MX and SPF
entries would have shown for each step along the way.
Take your time - we'll wait.
Please tell us - how much experience do you have with actually running
large
scale email systems? Can you tell us how much email you've processed
through
your zero-spam system, and the current rates of false positives and false
negatives?
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp