On 2/28/2013 9:33 AM, Rolf E. Sonneveld wrote:
Op 28-02-13 13:18, hector wrote:
Problem(s) to solve:
- (Detecting and) Rejecting Bad Guys,
oh, please, let's not try to solve all problems of the world here.
- Reducing Computers for Reception (turning off backups when primary
is up),
What problem are you trying to address?
I was extracting some of the issues within the threads, as you asked
for more. :) The OP proposed to "punish" the MTA who didn't follow
the MDA's MX order. I guess reducing the MTAs down to the primary only
would be one way to make the others unavailable. Not necessarily
punishing, but would just make it harder to deliver. If the server used
a permanent fail like a 550, this will hurt deliver by stopping
attempts. If it used a temporary 450, then a retry is scheduled. But
this will not stop it using a non-primary MX the next time. So nothing
gained. Therefore, to follow such an idea, you can only do one thing;
reduce the computers and perhaps that is the genesis of all this -
having one computer with multi-cores, enough to handle huge amount of
worker receiver threads, 25, 50, 100 or more using advanced IOCP
technology. Thats called scaling up where scaling out would be like the
old days with farms of multiple computers.
- Uniformity and Consistent Filtering Methods across MXes,
falls in category problem #3.
- RFC Error with implications that different MX and its order has a
direct correlation to quality of mail acceptance.
Can you elaborate on this? What error are you referring to?
Sure, I can see where the MX sorting and preference semantics starting
with 2821 can provide the idea that filtering can be done at the
secondary computers, hence different quality levels for acceptance.
That means if this was the case, part of the semantics, it would
drastically change the sender strategies and one perhaps where the first
MX would always be the only one attempted - why bother with the secondaries?
Overall, I don't think it was the intent to do filtering at the
secondary MXs. I don't really think its and error per se because this
is made clear in section 5.1 paragraph 3 by indicating a purpose for the
list of addresses - "To provide reliable mail transmission..."
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.
If there is ever a new 5321, it may be something to clarify.
Thanks
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp