Bruce Lilly wrote:
In order to work around a problem *at the provider* (or at
least *affecting the provider*), it was necessary to go
directly to a recipient's MX host. Your "solution", costs
aside, supposes that at least one of the providers is
unaffected by the problem
Okay, your solution was sending direct-to-MX with a MAIL FROM
listadmin(_at_)bruces(_dot_)box(_dot_)example and a HELO bruces.box.example
If bruces.box.example has no sender policy it works. If it
has "v=spf1 include:provider.problem.example a -all" it also
works. If you forgot the "a" although you sometimes send
direct-to-MX add it.
In theory you could arrange this for a DynDNS domain. Yes, it
would cost something. But the most expensive part of it is a
reliable MX provider, unless you think that an MX with a dyn.
IP is a cute idea.
In your specific pet case of "misdirected bounces"
Yes, these TeraBytes of crap, not only real bounces.
(think Comcast or RoadRunner)
Not at the same time, BTW, RR has an SPF policy. I never use
the other word for spamcast, unless it's in an SPF example for
spambot nets.
when I now have a problem with A I simply send the mail via
B, just using the corresponding MAIL
FROM:<my(_dot_)B(_dot_)address(_at_)B(_dot_)example>
That's OK for you, assuming that's where you *want* to
receive delivery notifications.
Of course. If there's some mail problem between B and C, then
adding A to the equation would only muddy the waters. And we
started with the assumption that there is a problem between A
and C, that's why I was forced to use the B-route.
That might not work for others.
Then they'll use other means to discuss it with A and / or C.
Your direct-to-MX solution is also fine. Just make sure that
you use a MAIL FROM corresponding to the route if you have SPF
policies, otherwise (no policy) do whatever pleaes you.
it won't work at all if you specifically want to delegate
handling of delivery notifications.
listadmin(_at_)bruces(_dot_)box(_dot_)example works. Only if you insist on a
MAIL FROM:<listadminATxyzzy.claranet.de> you'd need a new ISP,
that won't work direct-to-MX or via other providers. But as I
said I could manage it. This ISP even offers an alias that's
not SPF protected. So far I never needed it, zero problems.
Bye, Frank