<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/25/2014 03:08 AM, Murray S.
Kucherawy wrote:<br>
</div>
<blockquote
cite="mid:alpine.BSF.2.00.1401241104340.3104@medusa.blackops.org"
type="cite">On Tue, 14 Jan 2014, Andreas Schulze wrote:
<br>
<blockquote type="cite">consider a message with duplicate Reply-To
header.
<br>
Without this patch there is only this information available:
<br>
Jan 12 17:09:02 dmarc opendmarc[7682]: 3f2NBs3Hlkz259h: RFC5322
header requirement error
<br>
<br>
Patched the correct error is direct visible by the administrator
checking his logs.
<br>
Jan 13 02:08:16 dmarc opendmarc[9686]: 3f2c9m4TpSz259f: RFC5322
requirement error: more than one Reply-To: header
<br>
<br>
there are concerns about giving this information also the sender
via SMTP reply text. On one side the SMTP reply reveals what
changes might get bogus mail through the filter. On the other
side there are operational benefits helping good actors (admins)
to identify problems.
<br>
<br>
One can imagine to let the milter admin decide the behaviour,
give always information-less SMTP reply or give always a
meaningfull SMTP reply.
<br>
</blockquote>
<br>
Repeating this call for opinions. I'm currently of the opinion
that a responsible sysadmin (a) already is working to get her mail
to be compliant and is not really a concern, and/or (b) already
knows how to reach out proactively when mail is rejected,</blockquote>
<br>
I do not believe this ("already knows how to reach out") to be
correct. Perhaps a few thousand do, a very large multiple of that
don't.<br>
<br>
<blockquote
cite="mid:alpine.BSF.2.00.1401241104340.3104@medusa.blackops.org"
type="cite">so all you need to be able to do is reply with the
right answer when the question comes (i.e., the log should include
that detail). Everyone else should get a generic rejection
message that doesn't reveal anything about the local policy in
effect.</blockquote>
<br>
I'd suggest that there are two distinct cases of refusal worth
considering:<br>
<br>
<ul>
<li>Your message is out-of-spec (and I'm not willing to deal with
the downstream consequences of that).</li>
<li>Your message meets some other abuse control threshold,
disclosure of the details of which would compromise its
effectiveness.</li>
</ul>
Disclosing detailed information in the first case provides
negligible help to abusers (a) because the specs are public, (b)
because the refusal is trivially deterministic (vs. various
thresholds in the second case) and (c) because most abusers already
spend considerable time and effort studying the behaviour of
receiver systems (related to (b) in that trivially deterministic
refusals can be readily diagnosed by a motivated criminal). By
contrast, disclosing detailed information in this case does help
large numbers of smaller senders who aren't specialists, don't have
the motivation to spend the time that criminals do and are often
interested in doing the right thing (highly motivated in fact if
oversights are causing message refusal); detailed diagnostic
information helps here.<br>
<br>
Disclosing information in the second case - with the possible
exception of identifying reputation systems which provide
false-positive-error reporting web-pages - is helpful to an abuser
in that information may be disclosed that can't be obtained any
other way. It is therefore pretty clearly not a desirable thing to
do.<br>
<br>
<blockquote
cite="mid:alpine.BSF.2.00.1401241104340.3104@medusa.blackops.org"
type="cite">
I'd be willing to go as far as setting an SMTP reply that
indicates there was a message format error, but I'm not sure about
naming the specific header field that was malformed or absent
which caused the rejection action.
<br>
</blockquote>
<br>
This is receiver prerogative, clearly, but for the reasons above I'd
be inclined to provide a detailed explanation for refusals for a
message content being out of spec and no details at all for other
abuse control reasons.<br>
<br>
If naming the field (or some other detailed message for cases where
a field name isn't adequate) is a step too far, perhaps a pointer to
the relevant RFC.<br>
<br>
- Roland<br>
</body>
</html>