On Fri May 27 2005 23:03, Frank Ellermann wrote:
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
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. No way to change EHLO/HELO
(unconfigurable) [at least at that time], and in any event the
sending machine wasn't changed, so an EHLO/HELO change would
have been inappropriate.
Not at the same time, BTW,
So your scheme to do what I achieved in about a minute would be to
change SPF records under some domain that I have no control over,
wait for to TTLs to expire, and try again? Sounds rather cumbersome.
it won't work at all if you specifically want to delegate
handling of delivery notifications.
listadmin(_at_)bruces(_dot_)box(_dot_)example works.
No. You're presuming that there's an MX record (actually >= 2)
for such a thing and that there's a way to get mail there (due
to DHCP, the first is impractical at best, and the second is
prohibited by terms of service: "no servers").