Douglas Otis wrote:
You would not know which alias to use to overcome a problem
that can not be known in advance. : (
Not sure what you're talking about. Let's say that I send a
mail to somebody AT infradead mentioned here in other threads.
The receiver forwards this to a 3rd party without changing my
MAIL FROM. The 3rd party says "you are not allowed to forge
xyzzy addreses" and refuses to accept the mail. Infradead's
MTA returns the mail to me. That's IMHO working as designed.
I could fix this problem by using a MAIL FROM de.clara.net or
another mailer (today with all these BLs around we all have
at least one backup MSA, or at least I found that this is a
MUST HAVE).
But I wouldn't authorize the ill-behaved MTA to use my address,
neither directly by adding this MTA to "my" sender policy, nor
indirectly by modifying "-all" to something else.
That's not how I understand SMTP, for me the MX is meant as the
gateway to the receiver. It can forward, and relay, and do
whatever it wishes, but it _must not_ say MAIL FROM xyzzy while
talking with the MX of a 3rd party. If I'd wanted to send my
mail to this 3rd MX, then I'd do it directly.
Okay, it may change common practice for some systems, and it's
obviously different from what Dave said, but OTOH we're here in
MARID because there _is_ a problem with SMTP. Or rather more
than one problem, spf2.0/mfrom fixes only one of the problems.
I would expect BATV will be a good solution for this problem.
In theory it could be, but spf2.0/mfrom is something working
today with my MUA and my ISP. They didn't have to do anything,
only publish a sender policy with "-all". No new MTA.
Spf2.0/mfrom also offers something for the receiver, the MX can
reject all FAILs. That's also the reason why there SHOULD be a
"-all" in sender policies: Without "-all" or similar without
any FAIL mechanism at all, why should the receiver bother to
evaluate the sender policy ? SPF is a voluntary cooperation
between the (author of the) sender (policy) and the receiver,
and without a chance to get a FAIL the receiver has no reason
to cooperate.
Maybe I'd even implement it this way, if a sender policy has no
word starting with a "-" or a "redirect" stop the evaluation as
waste of time (yes, that violates several MUST in protocol-03,
but I could do it before calling check_host()).
It could be this assumption of acceptable losses holds
because far fewer use SPF to reject mail than publish
records.
That's of course possible, but in my infradead scenario there
are no losses. Hadmut published RMX in December 2002, RMX and
SPF were discussed over and over again, SPF started in January
2004, and so far the number of unexpected side-effects appears
to be minimal.
Forwarders and mail forgers have to adjust, yes. But that's a
feature and not a bug. I like it. Now please let's be done
with it, get the two RfCs out a.s.a.p., and then start to work
on other ideas like CSV, MTAMARK, or more SPF scopes.
As long as SPF isn't ready I don't trust other ideas, because
I'm not sure if that's only meant to derail SPF or create FUD.
Bye, Frank