[opendmarc-users] decision-making by consensus: SMTP replies

[Roland Turner]

On 01/25/2014 03:08 AM, Murray S. Kucherawy wrote:
> On Tue, 14 Jan 2014, Andreas Schulze wrote:
>> consider a message with duplicate Reply-To header.
>> Without this patch there is only this information available:
>>  Jan 12 17:09:02 dmarc opendmarc[7682]: 3f2NBs3Hlkz259h: RFC5322 
>> header requirement error
>>
>> Patched the correct error is direct visible by the administrator 
>> checking his logs.
>>  Jan 13 02:08:16 dmarc opendmarc[9686]: 3f2c9m4TpSz259f: RFC5322 
>> requirement error: more than one Reply-To: header
>>
>> 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.
>>
>> One can imagine to let the milter admin decide the behaviour, give 
>> always information-less SMTP reply or give always a meaningfull SMTP 
>> reply.
>
> 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,

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.

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

I'd suggest that there are two distinct cases of refusal worth considering:

  * Your message is out-of-spec (and I'm not willing to deal with the
    downstream consequences of that).
  * Your message meets some other abuse control threshold, disclosure of
    the details of which would compromise its effectiveness.

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.

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.

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

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.

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.

- Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.trusteddomain.org/pipermail/opendmarc-users/attachments/20140128/c9e49d15/attachment.htm>