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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp