The example which I mentioned in my previous email is an email which
was authored by a person. That email was sent through a web page.
Thanks for clarifying.
That would cause an email from an IETF reviewer to be rejected. The
"List-Unsubscribe" header in this case is not a good signal for
detecting emails which are not from a person.
Ok.
According to your proposal (Page 240),
the "verified strangers" uses a "challenge/response mechanism". How
does it prevent those "challenge" emails from being sent to the
domains used by the botnet? Will all emails which are not DKIM or
SPF "authenticated" be discarded?
I have used C/R only as an example. C/R part is optional. I have provided
other methods for C/R alternatives. e.g. Proof-of-Work.
Will all emails which are not DKIM or SPF "authenticated" be discarded?
"Chapter 6: Layers" section talks about 5 layers of my system. Encryption
layer (TLS), Authorization Layer (SPF), Alias Layer (SAD), Authentication
Layer (DKIM) and Alignment Layer (DMARC). When I originally designed the
system I mandated all 5 layers for certain type of boxes. So all 5 layers
result must be "Pass" to accept mails. But later I relaxed the requirements
only to Authorization Layer (SPF) and Alias Layer (SAD). You can see that
in Page 298 under "amendments" section. So DKIM is optional in my system.
For validation, we primarily rely on Authorization Layer (SPF). For
Domboxes, we check only the SPF record. But for Restricted Mailboxes we
give preference to the MX record. We first extract the MX record IP
addresses and compare with the Client IP. Then we go for SPF record, A
record and third-party MX host SPF record. The "Authorization Layer"
result is set during the "MAIL FROM" command. It can be one of: PASS,
NEUTRAL, FAIL
The mail rejection happens during the RCPT TO command. We first decide the
RCPT TO address box type. If it is a Restricted Mailbox, then it requires
"Pass" result for "Authorization Layer" to proceed. If "Authorization
Layer" result is "Pass", then everything looks fine so far. If not, then we
check whether "MAIL FROM" address is found in the recipient address book.
If found, then we fast-track the mail even though "Authorization Layer"
result is not "Pass".
If neither verified nor authorized in the address book, that's when we
reject the mail with an error message like "550 Restricted Box.
Unauthorized and Unverified Sender. Please configure SPF or Send this mail
from one of your MX server IP address"
To answer your question, Challenge mails will be triggered only on the
following conditions. (a) The sender is a verified stranger (b) The sender
is not found in the recipient address book. If those conditions are not
met, then the mail will be rejected with said error message.
Most botnet mails are from forged "from" addresses. So our "Authorization
Layer" result would be either "NEUTAL" or "FAIL" for botnet mails. If the
result is "PASS", that's when we go for "domain registration date" to rate
limit mails from fresh domains.
Hope that helps.
On Sat, Sep 28, 2019 at 1:50 PM S Moonesamy <sm+ietf(_at_)elandsys(_dot_)com>
wrote:
Hi Viruthagiri,
At 09:18 PM 27-09-2019, Viruthagiri Thirumavalavan wrote:
Usually noreply addresses are not falling under human-to-human
category. So we highly recommend our users to offload website
related and mailing list related mails to domboxes before enabling
restricted mode. That's because a dombox address gives exclusive
privilege to a domain and its alias domains.
The example which I mentioned in my previous email is an email which
was authored by a person. That email was sent through a web page.
But your concern is a valid concern. I think we should take
precautionary measures for challenge mails. For example, if the MAIL
FROM local-part contains text like "noreply" or "no-reply" and the
RCPT TO address requires CAPTCHA, then we should reject the mails
with an error message like "550 Recipient requires CAPTCHA. Not
possible in noreply addresses.". We can also use headers like
"List-Unsubscribe" to detect non-human mails.
That would cause an email from an IETF reviewer to be rejected. The
"List-Unsubscribe" header in this case is not a good signal for
detecting emails which are not from a person.
For the record, I'm not really a fan of challenge mails. But we
cannot just ignore it due to its annoying nature. For example, you
have a blog post and you see thousands of comments posted by bots
everyday. You get genuine comments monthly once. So it's reasonable
to enable CAPTCHA here.
Ok.
Plenty of people in the world use email address only for signing up
in third party websites like Facebook, Youtube etc. They hardly use
that for human-to-human communication. So CAPTCHA makes sense for such
folks.
Ok.
The key takeaway from my work is not the challenge part, it's the
"verified strangers" part. As of now, botnets plays a huge role in
email spam. Last time I checked there are botnets out there that is
capable of sending 92 billion spam mails per day. Mirai botnet
source code is available on the github. So you don't need much
technical skills to create a botnet. My system tries to bring those
spammers inside a circle by dividing the system into human mails and
non-human mails. My system tries to punish the domain rather than IP
addresse. So I believe it's effective in dealing with botnet spam.
I understand that there is some source code which could be used to
send a lot of unwanted mail. According to your proposal (Page 240),
the "verified strangers" uses a "challenge/response mechanism". How
does it prevent those "challenge" emails from being sent to the
domains used by the botnet? Will all emails which are not DKIM or
SPF "authenticated" be discarded?
Regards,
S. Moonesamy
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp