David MacQuigg wrote:
such slow progress in getting a complete workable proposal,
IMHO the IESG evaluation is very fast, and the draft is very
mature. It was published this year, the evaluation started
Jan 7, and fixing at least one of the two issues which caused
a DISCUSS-vote should be very simple.
including email forwarders
If you're talking about old "just change RCPT TO forwarders",
then there are too many workable solutions to list them all.
The most trivial solution is "don't" (= either behave like
a mailing list and change also the MAIL FROM, or say 551).
But that has nothing to do with "sender policies" because
it's strictly the business of the receiver.
| It is RECOMMENDED that SMTP receivers record the result of
| SPF processing in the message headers.
Why only RECOMMENDED? It seems like this will be a MUST for
forwarders.
The receiver either accepts a mail or rejects it. If you have
no whitelist the SPF-reasons why a mail was _not_ rejected are
not very interesting, a spammer can force any SPF-result he
likes. Excl. FAIL, but that normally results in an SMTP error
to the sender, not in a Received-SPF header for the receiver.
That's one constellation, where you cannot really say MUST, and
RECOMMENDED aka SHOULD is the next best 2119 term, exactly for
this purpose. The weak "maybe not" term is MAY aka OPTIONAL.
How else can they convey they results of their
authentication downstream?
If it's forwarded it wasn't a FAIL. You would exactly once
accept a mail which should have been rejected, then you'd block
this spam relay forever. It's the whole point of SPF that the
old-style forwarders are a part of the problem just like open
relays, if they refuse to upgrade their spam relay block them.
Bye, Frank