This is not backward compatible and does not work with indirect mail
flow. As an example, for aegee.org no SPF records
will be installed and the MX records will not be adjusted. It is up for
every user to choose which server it will use
to send emails. The lack of enforced DMARC validates this statement,
somehow. I *guess* for iki.fi the situation is
the same. The iki.fi provider handles only incoming emails, how users
send emails is up to the user (I guess).
When I meant backward compatible, I didn't mean all the systems on the
internet are already properly configured to be used with my system. I meant
majority of the cases can work properly with my system and the remaining
abnormal cases can able to easily recognise the problem via our error
message and then ask their administrators to configure the system properly.
Compare to having a system that does not accept * (asterisk) sign in the
local part of the email address
- such host cannot accept all valid emails.
I guess you are talking about my dollar-based disposable email address
structure here. We also have a subdomain based email address structure.
Our system can accept mails from both type of addresses. Even if that part
won't work, then we can start to hash the local part. So i'm sure we can
overcome those kind of issues.
I'm not sure whether you have gone through my paper. If you are not, I
would be really grateful if you go through my work and then judge my work.
Because sometimes you need context to understand why the system is designed
in that way. It's really hard to explain everything in a single blog post.
On Wed, Sep 25, 2019 at 5:40 PM Дилян Палаузов
<dilyan(_dot_)palauzov(_at_)aegee(_dot_)org>
wrote:
Hello,
example.com => RCPT TO: <user2(_at_)domboxmail(_dot_)com>
domboxmail.com => 550 Restricted Box. Unauthorized and Unverified
Sender. Please configure SPF or Send this mail from one of your MX
server IP address
This is not backward compatible and does not work with indirect mail
flow. As an example, for aegee.org no SPF records
will be installed and the MX records will not be adjusted. It is up for
every user to choose which server it will use
to send emails. The lack of enforced DMARC validates this statement,
somehow. I *guess* for iki.fi the situation is
the same. The iki.fi provider handles only incoming emails, how users
send emails is up to the user (I guess).
So it likely works with most setups, but if users want service that works
with all email flows, your system will not be
first choice. Compare to having a system that does not accept *
(asterisk) sign in the local part of the email address
- such host cannot accept all valid emails.
Regards
Дилян
As I mentioned earlier, my system is designed in a way to deal with spam
mails without wasting bandwidth. So all validation mechanism happens before
the DATA command..
On Wed, Sep 25, 2019 at 4:55 PM Alessandro Vesely
<vesely(_at_)tana(_dot_)it>
wrote:
On Wed 25/Sep/2019 12:29:44 +0200 Viruthagiri Thirumavalavan wrote:
In my system, challenge/response methods applicable only for
"verified
strangers". When the MAIL FROM says that the mail is coming from
john(_at_)example(_dot_)com <mailto:john(_at_)example(_dot_)com>, our
system going to
fetch the MX
record and check whether the mail is really coming from example.com
MX /receive/ mail, mailout hosts may differ and, in large sites, they
typically do.
Since we are talking about human-to-human mails here, we are
expecting the
mail from one of your MX servers. We also check SPF record and A
record. If
the mail is not coming from any of those IP addresses, we actually
reject
the mail.
SPF works better. However, consider the analysis depicted here:
https://en.wikipedia.org/wiki/File:Mailflows-reloaded.png
Many consider reject-on-SPF-fail dubious, which is why most mail sites
have
~all instead of -all. Rejecting on non-pass is definitely bad. DMARC
needs
simultaneous non-pass of both SPF and DKIM in order to reject.
However, the
most diligently authenticated messages are spam.
Best
Ale
--
_______________________________________________
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
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
