Re: [ietf-smtp] Reject messages on backup mail exchangers when primary M

On 2/27/2013 3:14 AM, Paul Smith wrote:
> On 26/02/2013 23:37, hector wrote:
> > The answer is not in the RFC.  If you used a 1000 messages on the 
> > first MX, you will run into trouble - pronto!!!! It would take 
> > forever sending mail one at at time. Of course, that first MX can 
> > expand to more host/IPs  but  if its only one or few IPs and there 
> > are more MXs, there are strategies in order to distribute more than 
> > one or a few at a time.  Throughput is very important for many.
> Well, there is also 'fairness'. While the sender may want to blast 
> their mailing list at every possible MX and every possible connection 
> on those MXs for a domain, it's entirely possible the receiver may be 
> more interested in the sales order that is also trying to come in, 
> rather than the car rental offers or whatever that are clogging up 
> their servers.
> 'Throughput' should be for the benefit of the receiver, not the 
> sender. It's inconsiderate to send using as many threads as possible 
> to a single receiver.
Hi Paul,

I agree a good throughput strategy includes an awareness of the 
resistance, the friction, the connectivity factors (such as limits) of 
the other end. The goal is always a smooth working software machine and 
communications system, no bumps!  :)
Since a receiver network can load balance, set limits, DoS controls, 
etc,  a more complex, prudent  scheme does include senders using the 
larger and/or entire MDA MX spectrum in the way they need it to work 
better for optimized and throughput reasons.    No one want constant 
overhead (retries) and resistance (rejects) with receivers.
One related case scenario that I was noticing last year with a 
newsletter customer,  was that their mailing list addresses with a wide 
spread of different domains, most seem to be hosted by the same vendor 
perhaps for AVS filtering.
So in other words,  you have 100 distinct domains which to us humans 
only, their domains names may suggest they are part of the same trade 
business/group, hence maybe explaining how they came about to use the 
same vendor hosting service.
But now what you may have in a typical single domain issue regarding MX 
and retries, it is now multiplied by a 100 because they are all served 
by the same hosting service with its pool of MXs allocated per customer 
domains.    The pattern was very clear.  The once successful fast 
parallel (concurrent) processing and connection for many domains 
providing  high throughput was now hampered with greater amount of 
hitting a new observed hosting vendor MX connection limits and also 
client IP limits.  It appeared to be an integrated  greylisting-like 
behavior but it also had a behavior where calling at a certain time 
(like after 5pm business hours) appeared to improve the connection and 
acceptance throughput.
I recall the only thing we needed to do was to make sure we provided the 
options for limiting and spreading the outbound mail MX expanded (and 
sorted by preference) IPs.   We also had to create Domain group profiles 
where you can lump domains into a profile with certain outbound, retry 
scheduling strategies.
Overall, in my experience, following RFC 5321 MX logic and let them fly 
(in parallel) worked well. For the larger loads, there might be a lot of 
stress as the race starts, but it tends to smooth out and eventually the 
mail gets there.  The Receivers are really good and robust about getting 
to much work.  The software rejects, the software adjust, etc.
--
HLS

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp