Da: Alessandro Vesely <vesely(_at_)tana(_dot_)it>
AFAIK, there is no way SMTP can be configured so that a given sending
location can be whitelisted. One can try and detect what MTA sends the
message and whitelist specific filters, presumably doing detection by
the IP address of each mailout. That's much like VPN: being at a
higher level doesn't ease the task. For example, assume someone trusts
Gmail's egress filtering and wants to skip content filtering for mail
coming from there. What work is required to accomplish (and maintain)
that task, on typical MTA software?
It's not clear to me if you're asking how the consent framework would deal with
the problem, but I can tell you.
Suppose that Gmail implements the consent framework in their MUAs. Then, MTAs
could whitelist Gmail with respect to the consent framework. Let's see what it
means to example.com's incoming MTA.
1. user1(_at_)example(_dot_)com is not consent-enabled. Then the framework is
not used, and nothing relevant happens, mail if acceptet/rejected as it
currently is.
2. user2(_at_)example(_dot_)com is consent-enabled, and a message arrives with
proper headers/tokens; then, the framework is deployed and the message is
accepted/rejected based on tokens (and some other usual controls), whitelisting
is not relevant
3 user2(_at_)example(_dot_)com is consent-enabled, a message without tokens
arrives from address(_at_)gmail, and gmail is whitelisted; in this case:
- user2(_at_)example(_dot_)com expressed the will to enable the framework;
- address(_at_)gmail can use the framework, since gmail is whitelisted, so the
sender MUA implements the framework;
- however, the message has no proper token; this means that user2 didn't
provide a token to the sender, and the message can be safely rejected, with no
need to other controls
This way, nobody can send messages to user2(_at_)example(_dot_)com with a
forged address from any gmail address (unless the attacker manages to get a
token from a user2's gmail correspondent). So, implementing the framework could
be of some interest e.g. to banks, since accessing their token should be
hopefully hard
4 user2(_at_)example(_dot_)com is consent-enabled, a message without tokens
arrives from address(_at_)gmail, and gmail is not whitelisted;
In this last case, we don't know if the message is without token because the
token was not provided, or because the gmail MUA doesn't implement the
framework and thus the token cannot be inserted in the message. It's up to the
receiver to decide if the message sould be rejected, or handled as if user2
were not consent-enambled (that is, go through the usual checks), which is what
would probably happen at least until the framework were widely implemented.
In any case, no work is required to the sender MTA, the sender
domain/organization is only required to implement the framework support in the
MUA
---
---
Claudio Telmon
claudio(_at_)telmon(_dot_)org
http://www.telmon.org
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg