Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version
Hector Santos <hsantos@isdg.net> Tue, 17 December 2019 23:04 UTC
Return-Path: <hsantos@isdg.net>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896031200B1 for <ietf-smtp@ietfa.amsl.com>; Tue, 17 Dec 2019 15:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Y7twgSN1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=YlwpCuP6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl4uVP-rzdxx for <ietf-smtp@ietfa.amsl.com>; Tue, 17 Dec 2019 15:04:33 -0800 (PST)
Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9850120116 for <ietf-smtp@ietf.org>; Tue, 17 Dec 2019 15:04:32 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5823; t=1576623863; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=6V0ynmw3Wk3cwpzeQ7Pt7qeijUU=; b=Y7twgSN1J1AzdT0zQsC9QUPbY6okX5akwdm9LlveT+lsEsEEzXxwg8jIMt0YMd 1te06WINkOwjgeR/pfXv5T14NNS3LAgH7h2345veFpOsnhc79mgM+uhbzpzP6zV5 NC9J6M7blx0Ya5vXtaTRdfVPDJ95M4LimFz8Gczr1PrLU=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for ietf-smtp@ietf.org; Tue, 17 Dec 2019 18:04:23 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 236245878.42331.7560; Tue, 17 Dec 2019 18:04:22 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5823; t=1576623709; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hW9yt6q FXb1j3AYv82y8D5WQSZ4Agxd2dw/0o6E8vUo=; b=YlwpCuP6cAZSkfD78I9STRu gSY4n3YvRt5Td9Sroo3QluYqsADQtJLCCpseyb0+HGtt+wm+INeGFtXapEStLNu6 l6+9CeT90HxQqnONsfI+tIxnX9+kg1EbbsV5ZQeMkP0G4Ql7LG13hYOp/yvxAKeA klgdOSxNeE2FfYOMLNb0=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for ietf-smtp@ietf.org; Tue, 17 Dec 2019 18:01:49 -0500
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 798889031.1.4856; Tue, 17 Dec 2019 18:01:48 -0500
Message-ID: <5DF95EF7.4050200@isdg.net>
Date: Tue, 17 Dec 2019 18:04:23 -0500
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: ietf-smtp@ietf.org, ietf@ietf.org
References: <8EE11B75E1F8A7E7105A1573@PSB> <m2a77ttff6.wl-randy@psg.com> <CABL0ig4Wz-0dk7bsRpaN6pni2rHEc-jPnygwed_Hygy+CiehQA@mail.gmail.com> <16306b3a-63bd-621e-636c-dd7626f74733@foobar.org> <DBADBA1F-5F81-4D14-8AF8-5F340F017DAC@ietf.org> <5DF92645.2090909@isdg.net> <E314E2AC-C69C-4828-AD5F-33C0EFD4E0FE@dukhovni.org>
In-Reply-To: <E314E2AC-C69C-4828-AD5F-33C0EFD4E0FE@dukhovni.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/nuwzHIMF80YzFf785O1xEKcNG8A>
Subject: Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2019 23:04:37 -0000
Viktor, I believe we are in agreement with the same principles. But maybe not. Not sure. I already implied local policy always prevails. That said, I believe the IETF "operational decision" was incorrect and inconsistent. To honor it, it may set a negative precedent for future implementer trust and confidence in protocol design. Is it advocating others to follow? After all, an SDO did it, so why not across all systems? We may have to explicitly embed this clause in the protocol: A "MUST NOT" protocol element MAY be overridden with "550" Policies. That is the implication we have here. Keeping in mind that these new 550 policies are generally based on some "Bad Guy" presumptions. It did not explicitly exist before RFC5321. Previously, 550 was like a "Catch all" reply code. Since 2003, with GreyListing, SPF, DKIM/SSP, DKIM/ADSP, DKIM/DMARC, etc, the beauty of these new protocols to help deal with "bad guys," they were ALL consistent with the written SMTP specifications. They did not change the SMTP protocol except for one thing. I was instrumental during RFC2821BIS in proposing and Klensin adding section 7.9. "Scope of Operation of SMTP Servers." With the advent of the new DNS TXT-based applications, we needed new SMTP justifications for rejections. The bar was raised for SMTP compliancy and correction. 7.9. Scope of Operation of SMTP Servers It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server. However, cooperation among sites and installations makes the Internet possible. If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the strengths of the Internet) will be threatened; considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process. In recent years, use of the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail. Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering. When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO (or HELO), MAIL, or RCPT as appropriate. What it needs to update here is to include DATA because of ADSP and DMARC. Again, now of the new augmented protocols did not change SMTP. For me, being consistent allows for raising the bar. In regards to the new ietf mail policy, if it was consistent with this new 550 policy to reject legitimate ip literals for a yet to be explained non-reason, it would be more consistent and acceptable, if it also consistently enforced a correct FQDN using a new 550 policy justification to reject IP::DOMAIN mismatches. After all a "real" MTA is expected to use rDNS to obtain the correct FQDN for the sender machine. No? That is not always optimal. Small lite weight SMTP clients exist. PTR slows them down. What if there is no PTR record? After all, again, more inconsistency, are we promoting PTR records now? For a certain period there, we were discouraging them, in fact, I think SPF tried to deprecate it. I am not going to bother to confirm but I recall the debates. Consistency with everyone "expected" to play by the same rules is paramount for maximum interoperability and with minimum support. IMO, this mail.ietf.org odd "operational decision" could drastically change things because now others will follow. I am still trying to understand why the legit IP-literal is being rejected in the first place. I don't see any legit reason for it. Do you? Thanks -- HLS On 12/17/2019 2:24 PM, Viktor Dukhovni wrote: >> On Dec 17, 2019, at 2:02 PM, Hector Santos <hsantos=40isdg.net@dmarc.ietf.org> wrote: >> >> But here is I see it: >> >> 1) Yes, everyone agree the response text needs to be fixed up, but >> >> 2) It is in fact a violation of RFC2821/5321 specification when a rejection is applied by a server to a perfectly valid ip-literal per specification, and > > It is not in fact. A receiving MTA can refuse your email for any reason. > As a matter of RFC-compliance it MUST recognize address literals as > valid syntax (which it did by returning a 550 rather than 500 or 501), > but is then free to reject them on policy grounds. > >> 3) It lacks consistency in its operational decision on what Client Mail/Host Names are rejected or accepted. > > This is also not true. It consistently rejects address literals because > doing so carries little risk of false positives (as already explained on > the ietf-smtp list, where the more technical discussion belongs). "Real" > MTAs use domain names. It is as simple as that. > >> If a rejection is going to apply to ip-literals, hence enforcing a FQDN, then at the very least, it should validate the FQDN. > > No, because enough "Real" MTAs use HELO domain names that don't map to > their own IP address, or any address at all. So the risk of FPs is > too high. > > There is no a priori discrimination here, it is all just based on what > one can get away with to reduce spam without blocking a non-trivial > volume of legitimate email. > >> The mail.ietg.org servers appears to accept any FQDN including a existing >> FQDN which does not match the connecting IP address and a non-existing FQDNs: > > As they must for operational reasons. > >> Yet, it does not validate the FQDN. Why? > > Because, much as one might want to, too many "Real" MTAs (sending > legitimate traffic) have FQDNs that would fail verification. > -- HLS
- [ietf-smtp] FWD: IETF Policy on dogfood consumpti… John C Klensin
- Re: [ietf-smtp] FWD: IETF Policy on dogfood consu… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Michael Peddemors
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Salz, Rich
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Randy Bush
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Salz, Rich
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… S Moonesamy
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Russ Allbery
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Brandon Long
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Paul Smith
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Paul Smith
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… John Leslie
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Paul Smith
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Alessandro Vesely
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Viktor Dukhovni
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Peter J. Holzer
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Russ Allbery
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Jeremy Harris
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Alessandro Vesely
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… John C Klensin
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… John C Klensin
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… John C Klensin
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… John C Klensin
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Alessandro Vesely
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Paul Smith
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Richard Clayton
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Dave Crocker
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Alessandro Vesely
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Richard Clayton
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Alessandro Vesely
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… John C Klensin
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… S Moonesamy
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Alessandro Vesely
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… S Moonesamy
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Sam Varshavchik