Michael Thomas wrote:
I'm aware that this is not legal, but these sort of things
happen in the real world, and are the kind of things that
cause interoperability and/or deployment issues. Since SSP
is a security protocol, we can pretty much be guaranteed that
somebody will eventually start probing the edge cases, so
to the degree that we can provide guidance is to the better,
IMO.
Some early SPF drafts tried to "ban" domain literals together
with weirder constructs. But that is a "receiver policy",
and HELO [1.2.3.4] from IPv4 1.2.3.4, or similar MAIL FROM:
<postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4]>, might be perfectly valid.
As far as a "sender policy" is concerned, IPv4 1.2.3.4 can't
have an SPF (or TXT) record, and therefore it's pointless to
talk about it in RFC 4408.
If you want a note stating that cases where it is impossible
to find an SSP are always "suspicious", what does that mean
for say a From: postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4] ? IMO that is no
job
for SSP, IPs simply cannot have a "sender signing practice".
There are numerous ways to create syntactically broken From
header fields, and if receivers bother to reject an SSP FAIL,
but accept syntactically invalid constructs, they are in need
of medication, not of convoluted prose in the specification.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html