Charles Lindsey wrote:
In other words, not all MX query gives you IP addresses to try.
So in that case, you can have an MX that directs you to the domain
nomail.invalid (which has no A record, of course) and that is the end of
the matter. What is wrong with that?
A change in long establish SMTP semantics and sending strategies.
The point is that the Sending Strategy is pretty much set by many
implementations.
What will be your strategy?
1 MX --> 1 A --> FAILURE --> REJECT?
Or will it follow the standard, with some following varying current
practices for performing exhausted retries?
Each implementation may have their own set of wrappers, for example in
Wildcat! SMTP, if enabled by the sysop, failure to deliver after the X
number of retries may get the domain blacklisted. We also have a CBV
(SMTP callback) and NXDOMAIN failures promotes 45x responses. It works
like a GREYLIST hence bad systems don't try again, good systems do.
Can it be augmented by a new SSP protocol by specifying a MX/A
requirement and recommendation for a change in SMTP sending strategy?
Possibly, it might be acceptable in that vain. SPF enforces FQDN
operations, SENDER-ID enforces RFC 2822 operations. Maybe SSP can
enforce MX operations.
But I don't think this will be accepted in general as part of the SMTP
especially because there is the presumption the remote system is a DKIM
system, when in fact, it may not be.
In addition, you have 2821 vs 2822 integration complications, which in
my view, one "total system" integration strategy is not going to be
generally acceptable by all. We have our set of integrated ideas. The
next guy has its own set as well.
I think SSP should stand on its own and then allow people to integrate
them with new proposals if they want to share their integrated business
methods. But it (SSP) should stand on its own.
My view.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html