I print on a business card my address t2(_at_)example(_dot_)org and give it to
humans. The humans store the email addresses in a
database. The database gets stollen and thus my address
t2(_at_)example(_dot_)org gets
stollen. Then a “website” sends emails to
t2(_at_)example(_dot_)org and the algorithm below says this is a
human-to-human
communication.
This scenario is perfectly fine in my system. The "website" domain's MX,
SPF and A records will be checked. The "website" domain will get
blacklisted if they are abusing the system. This is where C/R becomes
useful.
Returning challenge emails is nothing new, and is not a solution. It
imposes delays, and bothers the sender, just like
captchas bother the humans. It requires additional concentration from the
sender, who is supposed to answer the
challenge. In any case, as far as this can be set up per recipient and
the recipient decides to bother the senders with
email challenges, it is something that can be clarified between senders
and that recipient.
C/R mechanism is an optional mechanism in my system. We are not forcing
anyone to enable that. You can pretty much depends on the regular spam
filter here. Since we accept mails only from "verified strangers", it can
cut down a lot of spam.
On Wed, Sep 25, 2019 at 4:15 PM Дилян Палаузов
<dilyan(_dot_)palauzov(_at_)aegee(_dot_)org>
wrote:
Hello,
I print on a business card my address t2(_at_)example(_dot_)org and give it to
humans. The humans store the email addresses in a
database. The database gets stollen and thus my address
t2(_at_)example(_dot_)org
gets stollen. Then a “website” sends emails to
t2(_at_)example(_dot_)org and the algorithm below says this is a
human-to-human
communication.
This scenario is not so rare. Users use the same username and password
for different service providers. Once data
from any service provider is leaked, which happes regularly, that
credentials are tried as login on well-known email
providers and then all contacts stored in the addressbook of that email
provider get spam, from a mailbox they know (so
no challenge emails). Even if the mailbox is not used to send spam, the
hacker has the t2(_at_)example(_dot_)org address and the
new mail system cannot say anymore if the sender is human or bot.
As I said, first send emails from domains, whose MX records point to your
own servers, then propose improvements to the
global mail architecture.
When the MAIL FROM says that the mail is coming from
john(_at_)example(_dot_)com,
our system going to fetch the MX record and
check whether the mail is really coming from example.com.
You cannot know, if the sending site is entitled to send emails from
example.com by looking the MX records. MX records
are for setting the hosts to receive emails, not for fixing the hosts,
that send emails for a domain.
Returning challenge emails is nothing new, and is not a solution. It
imposes delays, and bothers the sender, just like
captchas bother the humans. It requires additional concentration from the
sender, who is supposed to answer the
challenge. In any case, as far as this can be set up per recipient and
the recipient decides to bother the senders with
email challenges, it is something that can be clarified between senders
and that recipient.
Another way to slow down spammers, is to return delayed OK on EHLO, RCPT,
MAIL FROM: and DATA END-DOT commands, with the
later not delivering the email, if the sender closed the connection before
seeing OK. Then spammers will have less
resources to send spam for the same unit of time.
Regards
Дилян
On Wed, 2019-09-25 at 15:06 +0530, Viruthagiri Thirumavalavan wrote:
And you tell that it's a "website related" mail, how, exactly?
You get a connection on port 25. How do you know it's really a real
person and
not a "website related" mail that lies in the From: field?
The system offers different address structures. We decide how to treat
the mail based on the RCPT TO address. If it is look like RCPT TO: <
john(_at_)example(_dot_)com>, then it's a human-to-human mail address. If it
looks
like RCPT TO: <amazon(_dot_)com(_at_)test123(_dot_)example(_dot_)com>, then
it's a website
related mail address.
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
address. We heavily rely on MX record instead of SPF record to detect mail
genuinity in human-to-human mails.
On Wed, Sep 25, 2019 at 1:37 PM Valdis Klētnieks <
valdis(_dot_)kletnieks(_at_)vt(_dot_)edu> wrote:
On Wed, 25 Sep 2019 10:16:13 +0530, Viruthagiri Thirumavalavan said:
In my system we are isolating only the website related mails.
human-to-human mails gonna work as usual.
And you tell that it's a "website related" mail, how, exactly?
You get a connection on port 25. How do you know it's really a real
person and
not a "website related" mail that lies in the From: field?
It's *really* easy to design a mail system that stops spam when
everybody follows
the rules. Making one that works even when the bad guys
intentionally break the
rules is a lot harder... And making one that works *and* that Joe
Sixpack will actually
use is damned near impossible.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp