Douglas Otis wrote:
SPF does not protect the HELO as checking is optional
Please look up RFC 2119 OPTIONAL / MAY vs. RECOMMENDED / SHOULD.
For checkers trying to figure out an empty MAIL FROM:<> it was
always required to use the HELO identity.
And no, there are no SPF policies for domain literals, checkers
would report a result NONE in this and similar cases.
SPF does not prevent bounces sent to those that did not send
the message without also reducing email's delivery integrity.
That's not the case, "reject any FAIL at your border" is the
very idea of RMX (one of SPF's predecessors).
Few SPF records have settings that operate in this mode as a
result.
Folks are free to publish records only enumerating PASSing IPs,
if they can't or don't wish to decide what to do with the rest
of the world. There are various scenarios where that can be a
good choice. I leave your DKIM "ideas" for DKIM experts here.
SPF expects recipients to not only check an MX record, but to
resolve the addresses for each target within an MX record and
to do this ten times over.
As far as the policy uses an mx mechanism, and there are 10 MXs.
In reality SPF is about _sending_ IPs, using the mx mechanism
is already unusual, because it's about MTAs _receiving_ mails
for the domain in question. Using 10 MXs is far more unusual,
after all the name server for the domain would like to answer
a query=mx without TCP. Ideally including the relevant IPs,
avoiding additional questions.
MTAs having trouble with query=mx would be also quite unusual.
Instead, verify the host of the SMTP client
Yes, that's the first step, see above.
then check for domain associations using a single DNS
transaction. This would be far safer in comparison.
That doesn't work for domains using more than one mail provider
to send their mails. All my ISPs would ask me what I'm smoking
if I'd propose to "associate" their outbound MTAs with a domain
xyzzy.dnsalias.org or similar.
On the other hand I could in theory associate this domain with
their services using SPF include:first.isp.example (etc.)
For your idea it would be more straight forward to revive 821
reverse routes, but unfortunately that failed a giggle test.
Great, Can-Spam, legal enforcement, and RFC 3865 to the rescue.
Is that a new all-time low in the history of the IRTF-ASRG ?
Spam must be made illegal. There should be no need for RFC3865,
or for legal provisions that say it is okay to spam provided your
message has a link that allows opting-out of this line of products.
A good part of the spam I get has opt-out links, nobody uses this.
It would be also hopeless to opt-out all local parts of a domain.
As you wrote later "opt-out" doesn't work.
There should be an international agreement that bulk sending
of unsolicited messages is illegal.
Until that exists and works I'm more interested in the technical
sides of the spam problem. Or of "misdirected bounces" wrt SPF
and 2821bis. IANAL and all.
Spam would end very quickly, and infections rates would decline.
From an IETF POV RFC 3865 offers anything that's needed for this
kind of legal FUSSP.
RFCs should be aimed at identifying who is _transmitting_ the
messages first.
If it's an SPF FAIL it wasn't xyzzy.claranet.de, problem solved
as far as I'm concerned. Similar GMane where I post this message.
And if it's an SPF PASS it's either me, or a problem between me,
my ISP, and another user of this ISP (= none of your problems) -
they can add op=auth to their policy when they are ready for it.
Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg