Re: [EAI] EAI and ADSP/DMARC

--On Tuesday, September 11, 2012 23:59 +0000 Franck Martin
<[email protected]> wrote:

> I'm moving all the threads away from EAI last call, as I think
> I feel better with the current last call documents. I have
> been advised to also post to [email protected]. So apologies,
> if I cross post and you miss a bit of history.

Thanks.  I suspect it should be moved off the EAI list as well.
I won't insist on that (yet), but you should consider it.

> So I read RFC6530 and I'll try to resume my understanding.
> 
> No MTA talking to another MTA will downgrade or upgrade an
> email. If the receiving MTA cannot handle UTF8, then the email
> will be bounced.

That is correct,  with one qualification.   If some MTA in the
system decides that avoiding the risk of blowback is more
important than properly delivering an NDN, the message
disappears.  I mention that in order to stress how little a MUST
means in the presence of what RFC 5321 describes as "operational
necessity".  If people are convinced that what the Standard
specifies is inappropriate or hazardous in their environment,
they will ignore the standard and do what they think is right.
In that context, the only difference between "MUST", "SHOULD"
and "Pretty Please" is whether the Standard looks silly when it
is ignored.  The choice of requirement words won't affect the
decision.

> Now the submitting MUA, will receive the bounce, and the MUA
> or the user may decide to provide an ASCII compatible email
> message, to be transmitted all the way. The RFCs do not seem
> to indicate specific ways to do a downgrade so that an
> International email can be converted into an ascii one and
> sent. It is left to the user may be with some help from its
> MUA to do this work.

Yes.  There is no "do not seem".  It isn't specified because
circumstances and remedies will differ too much depending on
what information is available and where.

> However what I see is the possibility, for the MUA to use the
> group syntax in the From: header and submit that to the MTA to
> deliver to the final MTA.

That MTA (really a Submission Server in today's vocabulary, see
RFC 6409) has to generate a backward-pointing envelope address
from somewhere to put into the MAIL command.  As far as I know,
there are only two types of methods in use: it figures the
address out from the headers of the message that MUA hands it
and it gets the information out of band.  If it has to figure it
out, it is pretty much stuck: the group syntax isn't permitted
in the envelope and there is no plausible transformation from
it.  FWIW, the Submission Server is prohibited (with a MUST)
from injecting an invalid message into the public Internet.  If
the backward-pointing envelope information is transmitted out of
band, I suppose that the MUA could supply group information in
the "From:" header field and a valid (and ASCII) address in the
envelope.  But that would be at least stupid and probably
malicious.  It is hard for me to believe that specific language
banning it --language that goes beyond the "don't do this"
language that already appears in
draft-leiba--5322upd-from-group-04-- would have any effect on
the author of an MUA who wants to do that or on the author of a
Submission Server who want to allow it.

So I think you are getting very excited about a non-problem.


> If my understanding is correct, this is an issue because the
> receiving MTA will not have enough information to provide a
> check using ADSP or DMARC. This case should not be allowed.

To say part of what I think John Levine has been saying, one of
the characteristics of FUSSP proposals in the past has been
that, having invented the FUSSP, not only the IETF will get in
line and change the way email works to accommodate your
solution, but those changes will deployed immediately worldwide
because the FUSSP is so important (see
http://www.rhyolite.com/anti-spam/you-might-be.html if you are
not familiar with it).  Not going to happen -- on the one hand,
there are lots of ways in which a receiving MTA (relay or
delivery server) may not have enough information to usefully
provide the checks you are looking for.  If the particular case
of a group in the "From:" header field is important enough, than
all an ADSP or DMARC procedure needs to do is to identify
messages containing such fields as non-validatable.  It isn't as
if there are no other circumstances that can result in a message
that can't be validated by those techniques.

> That a receiving MTA downgrade the From: into a group syntax
> for the MUA to be able to display the email to the end user,
> is an annoyance in terms of ADSP/DMARC but as mentioned the
> fix is for the end user to upgrade its MUA. ADSP/DMARC would
> have already been applied to the email at this stage, so no
> core functionality would be lost in that transaction. The MTA
> would also have added Authentication-Results: header with the
> necessary information to indicate the result of SPF, DKIM,
> ADSP, DMARC. However this header is not easily visible to the
> end user. The DMARC spec can alert people about this case in
> Security Considerations, i.e. We could live with it.

Ok.

> So in summary, my opinion is that a submitting MUA MUST NOT be
> allowed to use the group syntax when submitting an email to an
> MTA. Corrolary a MTA MUST not accept an email where the From:
> header contains the group syntax and should bounce that email.

See above.  Good luck with that.

> I think this course would keep the security benefits that
> ADSP/DMARC provide to the email environment.
> 
> Did I miss something?

Yes.  See above.

>...

    john
 
p.s.  I use different subscription addresses on different IETF
mailing lists.  If I were to try to reply to your message
accurately with a message that would be posted by the mailing
list expander to the EAI and ietf-822 or ietf-smtp lists, just
about the only way to do it would be to put multiple addresses
in the "From:" header, one that corresponded to each list.  Yet
another example of where that construction is potentially useful.


_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822