Bruce Lilly wrote:
[problem with the mail provider]
your solution was sending direct-to-MX with a MAIL FROM
listadmin(_at_)bruces(_dot_)box(_dot_)example and a HELO bruces.box.example
No, neither MAIL FROM nor HELO/EHLO were changed. no point in
changing MAIL FROM, as the intent was not to change where
delivery notices were sent.
Now it sounds like an ordinary alias-style forwarder to third
parties (5.3.6(a) in 1123). We already discussed this case,
it's also addressed in the SPF draft, and the short form is
"it doesn't work with SPF".
That's unrelated to your example "technical problem with the
mail provider", it doesn't work even without this problem.
In fact it _could_ work in several ways, e.g. if the senders
add your mailouts to their sender policies, then you're free
to keep their original MAIL FROM. Or if the receivers white
list your mailouts as "trusted forwarders", maybe depending
on the RCPT TO, it's also okay.
Let's assume that it doesn't work, but you never noticed it,
because you mail provider handled it. Now you're trying to
forward direct-to-MX. The MAIL FROM is protected by an SPF
FAIL policy, it doesn't permit a:bruces.box.example, and the
MX checks SPF.
Then you get a reject from the MX, and you create a bounce
message to the original sender. Ready, that's all, just like
a "551 user not local", working as designed.
There are essentially three ways to make it work with SPF:
- the sender policy adopts your MTAs ("Bruce is one of ours")
- the receiver white lists your MTAs ("I trust Bruce's MTAs")
- you take the responsibility for this mailing list, 5.3.6(b),
using your own MAIL FROM
You're of course free to say that it's not your problem what
the sender and the receiver do, and if the pseudo-551 bounces
annoy you talk with the sender.
your scheme to do what I achieved in about a minute would be
to change SPF records under some domain
No, I would just take the responsibility for the redistribution
and use my own MAIL FROM. In reality I'm not planning to host
a mailing list.
For my original example "problem with A, therefore send via B"
SPF was irrelevant, my UA automatically uses the MAIL FROM for
B if I send via B.
And B was an SMTP-after-POP "MSA" enforcing submission rights
(2476 6.1), I had to say MAIL FROM:<my(_dot_)address(_at_)B(_dot_)example> - it
wouldn't let me send any MAIL FROM:<nobody(_at_)xyzzy>. That's as
it should be, especially for SMTP-after-POP. Adding SPF FAIL
for A = @xyzzy didn't change anything for this MSA provider B.
You're presuming that there's an MX record (actually >= 2)
Second time you mention MX > 1, are you sure that you don't
confuse this with NS > 1 ?
(due to DHCP, the first is impractical at best, and the
second is prohibited by terms of service: "no servers").
Reliable MX services are something you can arrange (e.g. buy),
the place where I got xyzzy.dnsalias.org offers it - no, I
don't use this "dnsalias" as mailout, therefore I also don't
need a reliable MX, but _in theory_ I'd know where to get it.
Again, _in theory_ and of course compatible with SPF. This
theoretical case starts to get more interesting with MTAMARK.
Bye, Frank