On 12-05-13 01:21 PM, Alessandro Vesely wrote:
On Sun 13/May/2012 18:59:23 +0200 Chris Lewis wrote:
On 12-05-13 05:58 AM, Alessandro Vesely wrote:
On Sun 13/May/2012 11:07:45 +0200 Chris Lewis wrote:
It would be nice if it could be made usable.
This would tend to make a large organization having all of their servers
helo exactly the same way, which flies in the face of industry BCP (eg:
MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly
violates its intent.
I see nothing wrong if an organization uses the same helo name for all
its mailouts. A helo name does not have to be a label of any DNS
record.
Uh what?
RFC5321:
Section 4.1.1.1:
These commands are used to identify the SMTP client to the SMTP
server. The argument clause contains the fully-qualified domain name
of the SMTP client, if one is available.
This has been discussed so many times that we don't need to do it once
more. For one (John Klensin on Jan 2009):
The 1123-imposed requirement (carried forward into Section 4.1.4
Paragraph 6 of 5321) that messages not be rejected on the basis
of a validation failure with the EHLO argument would presumably
remain even if we deprecated 821 and client use of HELO.
http://www.imc.org/ietf-smtp/mail-archive/msg05420.html
On the one hand, we have Klensin commenting on rejecting email based
upon helo validation (despite which, helo factors very heavily into
filtering anyway), versus _explicitly_ violating the RFC in a proposed
standard.
Klensin's argument doesn't apply to this proposal. At all.
Yeah, I suppose you could make all your outbounds have the same name (up
to whatever limit DNS imposes), but clearly this violates the intent.
And it's also very explicitly counter to industry practises/BCP.
I'd agree that violating intents and/or practices is not a good start.
That seems to imply that it is necessary to use scripts to keep helo
names, IP addresses, and SPF in sync. Would that be worth?
The reality is going to be is that since it relies on SPF to be valid,
few people would bother implementing it on the sending side, and there
will be more than enough people ignoring the requirement to SPF verify
before trusting it, that kabooms! will still happen.
There are other ways of doing this that doesn't require ancilliary gunk
like SPF. There's at least one IP-based DNSBL that yields the same data.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg