Re: [mailop] A proposal for automated management of mail sending limits

[Federico Santandrea]

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 delivering the mail 
they need to deliver, so I can't picture a choice of values to 
publish that would be of value to (or could be followed by) most 
senders.


That's what I meant, limits for "strangers"; because of course every
peer who establishes any kind of reputation would be subject to
limitations unique to that peer and that mail flow, and know better. It
was meant to show a starting point for newly or rarely seen providers.


On 14/11/2017 16:24, Ken O'Driscoll wrote:

However, Specialist MTA designed for bulk sending, such as GreenArrow
or PowerMTA can be configured to control mail flow on a very granular
level on a per provider, IP, MX etc. basis. They also support
dynamically changing mail flow in response to throttling.


I am aware of how specialist MTA can assess sending limits on their
own; what I was seeking was a less intrusive alternative to the de facto
standard practice of slap-on-the-wrist-until-you-know, i.e. using
throttling as signalling.

After reading everyone's replies, I realize this is not as useful as I
thought at first. In fact anyone using appropriate software would only
have any use for this for the first handful of messages to somewhere
new, which when you send volumes is a negligible part of the whole. And
then you'd need to bump against the limits anyhow if you need to send
more.

I agree this is probably not worth pursuing.

--
Federico

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] A proposal for automated management of mail sending limits

[David Hofstee]

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 this falls short. I don't know if you have seen how Message
Systems' "Adaptive Delivery" works? It only works for about 75 ISPs and
only for fixed domains (barely adequate in my opinion). Not sure what Green
Arrow can do.

The problem I see is that it requires extensive tuning. Small shops don't
do that because they lack expertise, data and time. If we want email to
remain accessible, we should remove this obstacle.

Yours,


David

On 14 November 2017 at 16:24, Ken O'Driscoll  wrote:

> 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-trying. That works for
> small delays, such as "Server Busy - Try Later" but doesn't really scale
> for the throttling experienced during bulk sending. You can use multiple
> queues but that only results in email often being delayed unnecessarily.
>
> However, Specialist MTA designed for bulk sending, such as GreenArrow or
> PowerMTA can be configured to control mail flow on a very granular level on
> a per provider, IP, MX etc. basis. They also support dynamically changing
> mail flow in response to throttling.
>
> So legitimate bulk emails sent though a specialist MTA aren't typically
> unduly hindered by pre-acceptance throttling etc.
>
> But I do think that this issue isn't as much an engineering problem as a
> communications one.
>
> Ken.
>
>
> --
> Ken O'Driscoll / We Monitor Email
> t: +353 1 254 9400 | w: www.wemonitoremail.com
>
> Need to understand deliverability? Now there's a book:
> www.wemonitoremail.com/book
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>



-- 
--
My opinion is mine.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Random question about complaints

[Nick Schafer]

Hi there awesome email community!

I wanted to do some due diligence on a question we had come in from a
customer so figured asking the community for their thoughts would be a good
start.

Basically, we received an ARF report from an ISP so we take that as a
recipient complaining against a message from one of our senders. That
recipient then reached out to the sender swearing up and down that they
never complained.

My question is, is there anything that could inadvertently trigger a spam
complaint for a recipient without their knowing? My hunch is some sort of
mailbox add on or something to that extent but wanted to hear others
thoughts.

Of course, the recipient may have accidentally clicked "spam" or "junk" and
they just forgot :)

Best,


Nick Schafer
Technical Account Manager, Mailgun 
Add me on LinkedIn 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Random question about complaints

[Ken O'Driscoll]

On Wed, 2017-11-15 at 11:56 -0600, Nick Schafer wrote:
> My question is, is there anything that could inadvertently trigger a spam
> complaint for a recipient without their knowing? My hunch is some sort of
> mailbox add on or something to that extent but wanted to hear others
> thoughts.
> 
> Of course, the recipient may have accidentally clicked "spam" or "junk"
> and they just forgot :)

Some users hit "spam" when they want to unsubscribe, others when they want
to move a mail out of their inbox.

Some users also consider their trash folder to be a valid place for storing
previous correspondence.

The user in question could also have created an automatic filter that
matched a particular key word and marked those emails as spam.

Bottom line is that you don't know what they're doing, how they use email
or how a mailbox provider will treat some of their actions (particularly
automated ones).

Occasional false positives are part of the course.

Ken. 

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] "Temporary System Problem" from Gmail?

[Allen Kevorkov via mailop]

Greetings! Is anyone else seeing "421 4.7.0 Temporary System Problem. Try again 
later (MU). r9si1981163qtf.177 - gsmtp" from our friends at Google? 
Thanks!
Allen K___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Random question about complaints

[Nick Schafer]

Thanks all! Very helpful and inline with what I was thinking!

Nick Schafer
Technical Account Manager, Mailgun 
Add me on LinkedIn 

On Wed, Nov 15, 2017 at 12:27 PM, Ken O'Driscoll 
wrote:

> On Wed, 2017-11-15 at 11:56 -0600, Nick Schafer wrote:
> > My question is, is there anything that could inadvertently trigger a spam
> > complaint for a recipient without their knowing? My hunch is some sort of
> > mailbox add on or something to that extent but wanted to hear others
> > thoughts.
> >
> > Of course, the recipient may have accidentally clicked "spam" or "junk"
> > and they just forgot :)
>
> Some users hit "spam" when they want to unsubscribe, others when they want
> to move a mail out of their inbox.
>
> Some users also consider their trash folder to be a valid place for storing
> previous correspondence.
>
> The user in question could also have created an automatic filter that
> matched a particular key word and marked those emails as spam.
>
> Bottom line is that you don't know what they're doing, how they use email
> or how a mailbox provider will treat some of their actions (particularly
> automated ones).
>
> Occasional false positives are part of the course.
>
> Ken.
>
> --
> Ken O'Driscoll / We Monitor Email
> t: +353 1 254 9400 | w: www.wemonitoremail.com
>
> Need to understand deliverability? Now there's a book:
> www.wemonitoremail.com/book
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Timeouts on "." sending to nic.ru

[Grant Taylor via mailop]

On 11/14/2017 06:03 PM, Mark Milhollan wrote:
satellite can be terrible and links into disaster areas can 
be worse, not even counting personal or overloaded servers


Why are obvious problem links significantly influencing current standards?

If I were to stand up a link across such a hostile connection, I would 
put a smart host on either end that is extremely tolerant of the poor 
connection in the middle.  The smart hosts would then (hopefully) 
respond within more reasonable time frame to systems on their respective 
ends.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DHL.com email admin contact?

[Dave Warren]

I'm not actually seeing how this is DHL's fault. DMARC requires either
DKIM *or* SPF to pass, if you're misconfigured such that you're breaking
SPF that would seem to be your issue more than DHL's.
In an ideal world, senders would aim to pass both DKIM and SPF, but if
you're intentionally breaking half of DMARC then you should probably
switch off DMARC completely.

On Tue, Nov 14, 2017, at 09:08, Joe Klein wrote:
> Hey list!


>  


> Does anyone have an email admin contact for dhl.com (or .de given the
> RTT I’m seeing from their MTA)>  


> Having a problem with one of their MTA’s not DKIM signing emails and
> these emails are getting rejected by my client’s mailbox provider
> because dhl.com’s DMARC is set to REJECT. These emails are going
> through my Barracuda spam/malware filter on their way to the mailbox
> provider thereby failing SPF too.>  


> Trying to call DHL’s support number for something like this probably
> won’t be all that successful and no response from my email last week
> to postmaster.>  


> Thanks!


>  


> -joe


> _
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop