On 12/15/2019 4:24 PM, John C Klensin wrote:
In the likely event that not all readers of the ietf-smtp list
are following ietf(_at_)ietf(_dot_)org, I am forwarding the following for
your information. People will do what they decide they need to
do, but my hope is that we can separate the discussions of what
5321 (or 5321bis) says or ought to say, technical issues with
error responses, etc., from questions about why the Secretariat
was told to reject IP literals,whether whatever process produced
those instructions is appropriate going forward and, if not, how
the relationships should be adjusted.
From my point of view, we should not ask the Secretariat to make
changes to the instructions they were given on the basis of
discussion on this list, even if a clear consensus emerges.
Instead, either whatever "leadership" decisions produced those
instructions need to change them or the IETF community needs to
fix those mechanisms. Those issues are, IMO, a matter for the
IESG and the IETF list (or, if needed, late feedback to the
Nomcom).
john
Hi John,
I wanted to point out something.
While the mail.ietf.org is raising the bar by requiring a FQDN, it is
also not checking the FQDN validity. I did two test using an existing
FQDN that does not match the connecting client IP and a non-existing
FQDN from the same IP machine:
EHLO santronics.com
EHLO foo.santronics.com
Each were acceptable, especially foo.santronics.com
So it wants a FQDN and yet doesn't check it. Why?
Because we have a history of this check being unreliable, hence why a
MUST NOT reject on the basis.
But why the rejection of a IP-literal if it won't even check if the
FQDN is even exist or if it matches any of the IPs or even the SPF. I
don't get it. They need to explain this. What I see is a poor
implementation of some aggressive anti-spam filters. Yet, from what I
can see, it is not doing any SPF check before the DATA command. I
gave it a fake machine host name and a return path with a HARD FAIL
SPF policy and it accepted the information:
S: 220 ietfa.amsl.com ESMTP
C: EHLO foo.santronics.com
S: 250-ietfa.amsl.com
S: 250-PIPELINING
S: 250-SIZE 67108864
S: 250-ETRN
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250-AUTH=PLAIN LOGIN
S: 250-ENHANCEDSTATUSCODES
S: 250 8BITMIME
C: MAIL FROM:<hsantos(_at_)santronics(_dot_)com>
S: 250 2.1.0 Ok
C: RCPT TO:<ietf-smtp(_at_)ietf(_dot_)org>
S: 250 2.1.5 Ok
If it is going to be anal for ip-literals, it should also check if the
FQDN even exist at the very least, and if it has SPF supports, it MUST
NOT accept the given MAIL FROM, but its probably delaying this until
DATA if its going an DMARC check.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp