Re: [dispatch] FYI draft-levine-mailbomb-header-00

Did this draft get followed up on?

I think it’s a good idea. I have seen form submission systems include this information in e-mail payload data, so there is a use case.

I do not share the privacy worries: if the system does not want to include it, it does not have to. It is up to the system and the local regulations under which it operates.

Other than the obvious need to clarify the ABNF, I think that it would be reasonable to reuse some syntax from another Internet standard for IP addresses, to handle “IPvFuture” (see, e.g., RFC 3986; General-address-literal of RFC 5321, etc.) without needing to update this document. On the other hand, if you take the exact syntax from another Internet standard, you may not be able to redact the IP address so easily: the ABNF would be different so the implementation would also be different.

Sean

> On Jun 21, 2017, at 2:27 AM, John R Levine <johnl@taugh.com> wrote:
> 
>> For v6, how much would typically be redacted ?
> 
> I get the impression it'd usually either be the high half or the low half. We worked this out with some German ISPs who had strong opinions about what they would be allowed to include.
> 
> Keep in mind that the alternative to a redacted IP is not a full IP, it's no IP at all.
> 
> R's,
> John
> 
>>> On Jun 19, 2017, at 11:42 AM, John Levine <johnl@taugh.com> wrote:
>>> 
>>> This draft came out of a discussion last week at M3AAWG.  The issue is
>>> that bad guys (or more likely bad bots) fill out web forms and include
>>> fake mail addresses, the forms provoke confirmation mail which then
>>> mailbombs the address(es).
>>> 
>>> This draft adds a new header to indicate that a message is in response
>>> to a form submission:
>>> 
>>> Form-Sub: v=1; ip4=198.51.x.x
>>> 
>>> The IP address is that of the web client, which may be partly redacted
>>> with "x" for privacy reasons.  If a recipient mail system sees too
>>> many of them, it may block the system that's sending them.  The draft
>>> also asks for an enhanced status code which means we rejected this
>>> message because it's part of a flood with Form-Sub headers.
>>> 
>>> When we had the discussion there were people from at least two large
>>> consumer mail systems and a dozen hosters and (sending) mail service
>>> providers in the room, so it is likely this will be implemented
>>> enough to see if it's useful.
>>> 
>>> At this point the main point of writing the draft was to have a
>>> reference so I could ask IANA to register the header and status code.
>>> If it does turn out to be useful I'll come back and ask for it to be
>>> dispatched into a standards track document.
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch