Le lundi 26 Juillet 2004 22:02, Greg Connor a écrit :
In my opinion, if you want to define 2821 as Transport and 2822 as
Content, that is fine, but there are still cases where you need to sync
up the two. How do you solve this puzzle? If the MTA only has access
to 2821 identities, and the MUA can only see 2822 identities, then
neither of these can validate consistency without stepping out of its
assumed boundaries.
I don't really understand this necessity of "syncing" envelope with contents,
unless I missed an essential part of the goals of MARID.
The major problem we have to face today regarding this is the huge quantity of
spam/viruses that comes from zombie or exploited machines around the world,
that pick-up a random e-mail address, connect directly to the destination MX
and say:
HELO destination-domain.com (or whatever)
MAIL FROM: <random_address_picked_in_address_book(_at_)forged_domain(_dot_)com>
We aren't out to prevent the user from sending from work a mail which headers
state "From: <my_personnal_address(_at_)my_home_isp(_dot_)com>, we are out to
prevent
the massive disruption of e-mail that all these zombie and trojaned machines
cause.
And this can perfectly be achived without having to "sync" envelopes and
contents, or even to worry about contents at MTA level.
It would be enough to use SPF + SRS plus maybe some specifics for bounces, AND
enforcing readily available state-of-the-art techniques.
If you publish a RFC saying:
1/ A machine that wants to send mail out MUST HELO using its FQDN, and the
given FQDN MUST resolve in DNS to its actual IP address, otherwise receiving
side SHOULD reject the connection.
2/ The machine that wants to send mail SHOULD be listed in SPF as a legitimate
mail sender for the HELO it gave. i.e. MAIL FROM:
<MAILER-DAEMON(_at_)given_helo(_dot_)com> SPF check SHOULD give "pass" and MAY
give
"neutral" or "none" (in these 2 last cases, the receiving side policy MAY
decide to refuse the connection), but MUST NOT give "fail", "softfail",
"error" or "unknown" otherwise the receving side SHOULD reject the connection
with a 4xx temporary error.
4/ The given MAIL FROM: MUST be replyable (its right-hand part must resolve in
DNS either to an A or a valid MX record) otherwise the mail SHOULD be
rejected (most MTAs already implement this check); but in case of a DSN (MAIL
FROM: <>), then we should make the check using the given HELO.
3/ The given MAIL FROM: SPF check SHOULD give "pass" and MAY give "neutral" or
"none" or "softfail" (in these 3 cases the receiveing domain policy MAY
decide to reject the message or submit it to further checks), and with an SPF
"fail" the receiving side SHOULD reject the message with a 5xx permanent
error.
Now, with this, you are already sure that you will only accept mail from
machines that HELO properly with their real name, that are authorized mail
sender for their domain (receivers can push towards SPF adoption by deciding
massively to reject connexions for domains that have no SPF record).
Then the SPF check on the MAIL FROM permits checking that the sender is
actually allowed to send from this machine, and SRS solves the forwarding
issue.
At this step, you know that all e-mail you accept to receive comes from a MAIL
FROM and a sending MTA that are mutually coherent, and authorized.
At this step, all e-mail from forging zombies is eliminated, and this is the
main result we want to achieve.
Then, we could simply recommend that MUAs SHOULD display the <Return-Path> as
well as the "From: " header field, and simply educate users in telling them
that, when they differ, and if in doubt about the authenticity of a given
message, the <Return-Path> is credible where the "From: " may not be.
We already have almost all the needed tools for achieving all this (and they
already prove usable and efficient), without having to invent a very COMPLEX
system such as PRA + SUBMITTER that doesn't give any true assurance that it
can perform any better than what we already have readily available.
The PRA + SUBMITTER system really looks to me like a kludge on a kludge on a
kludge, and if I'm not sure it will perform any better than a much simpler
system such as what I suggest.
In France, we have a Shadok joke that says "Why do simple, when we can do much
more complicated ?"
And that's exactly what PRA + SUBMITTER evokes to me.
--
Michel Bouissou <michel(_at_)bouissou(_dot_)net> OpenPGP ID 0xDDE8AC6E