<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>