Hi Ken,
The part after the snippet, is where I explain why I said that.
Only in recent years has PowerMTA 4.5 added some more granular options,
maybe after me complaining about it. It used to be per (set of) domains
only (and the added routing). I looked at the 4.5 features and I still
presume th
Thanks to everyone for taking the time to read and give feedback.
On 13/11/2017 18:58, Steve Atkins wrote:
If the ISP were to publish the constraints that were applicable to
SMTP from strangers they'd often be low enough that many senders
wouldn't be able to comply with them while still delive
On Tue, 2017-11-14 at 10:05 +0100, David Hofstee wrote:
> I agree that it is a problem. I do think this could be done at connection
> time only. Of of the tricky parts is that all mail servers I know have
> trouble with throttling.
[...snip...]
Traditional MTAs often respond by queuing and re-tryi
I agree with Ken that the need for guidelines is well intended. Many legitimate
senders want to avoid pushing too hard and wasting resources on both ends. But
I think exchanging specific limits between receiver and sender via a new
mechanism is infeasible, and may not even be needed.
Why not st
Hi Ken,
I agree that it is a problem. I do think this could be done at connection
time only. Of of the tricky parts is that all mail servers I know have
trouble with throttling. They can throttle on a (set of) recipient
domain(s), but not on a cluster of MXs from e.g. Microsoft. E.g. they put
hotm
On Mon, 2017-11-13 at 09:58 -0800, Steve Atkins wrote:
> (If this proposal were coming out of a group of major ISPs or a few of
> the larger inbound mail appliance or service providers as "this is
> something we want to do" I'd consider it differently than it coming from
> the high volume email dep
Just a note:
draft-santos-smtpgrey suggests to tell the sender when to try again,
e.g., 451 Greylisted, please try again in # seconds
Maybe something like that would be the right approach for this case
too? You could announce the limits for the client in the greeting,
e.g.,
250-CONCURRENT-CONNECT
On 13 Nov 2017, at 9:05, Federico Santandrea wrote:
Hello,
I am working on a rough draft for a protocol meant to facilitate
exchange of deliverability information among ESPs and mailbox
providers.
This arose from the observation that providers who choose to publish a
description of what
On Mon, 2017-11-13 at 18:05 +0100, Federico Santandrea wrote:
> Would this fill anyone else's needs and benefit the community?
> Any feedback is appreciated.
Most pre-acceptance filtering is dynamic and based on other sender
reputational indicators meaning throttling thresholds can vary dramatical
> On Nov 13, 2017, at 9:05 AM, Federico Santandrea
> wrote:
>
> Hello,
>
> I am working on a rough draft for a protocol meant to facilitate exchange of
> deliverability information among ESPs and mailbox providers.
>
> This arose from the observation that providers who choose to publish a
>
I recall at a M3AAWG meeting about a year ago this idea did not have much
enthusiasm.
One big issue will be dynamic values. For example, one IP might be allowed
more connections than another based on other historical data (aka
reputation). We also know that the published info on some of the postma
Hello,
I am working on a rough draft for a protocol meant to facilitate
exchange of deliverability information among ESPs and mailbox providers.
This arose from the observation that providers who choose to publish a
description of what they consider to be an acceptable mail flow, do this
eac
12 matches
Mail list logo
