Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Dave (FitEyes)]

On Sun, May 13, 2012 at 9:45 AM, Joe Sniderman <
joseph.snider...@thoroquel.org> wrote:

> On 05/13/2012 01:39 AM, David wrote:
> > For a mailing list, would I have to expand my SigningTable in any
> > way?
>
> No, as long as the list's domain is in your SigningTable.
>

OK.


>
> If you want to sign outgoing messages, you probably want to sign based
> on the list's domain, rather than the poster's domain.
>
> By default, OpenDKIM only looks at the "From" message header to
> determine the sender.
>

I see. That's exactly what I needed to know.


>
> SenderHeaders   Sender,From
>
> to your opendkim.conf *should* resolve the problem.
> FWIW, making that config change resolved the issue in my case. YMMV.
>

Thank you. This is the most amazingly helpful list I have ever been on. The
Mailman community is awesome.
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Joe Sniderman]

On 05/13/2012 01:39 AM, David wrote:

[snip]

> If you think of anything, please let me know. I have been reading all
> the DKIM related posts I can find, both on this list and other
> places.
> 
> For a mailing list, would I have to expand my SigningTable in any
> way? 

No, as long as the list's domain is in your SigningTable.

> My opendkim SigningTable currently only has an entry for 
> *@list.example.com(which is associated with list._ 
> domainkey.example.com).
> 
> But /var/log/mail.log shows a lot of entries like this:
> 
> no signing table match for [some member of the list]

OpenDKIM is seeing the subscriber's domain as the sender domain, and is
basing its decision not to sign on the fact that the poster's domain is
not in the signing table.

If you want to sign outgoing messages, you probably want to sign based
on the list's domain, rather than the poster's domain.

By default, OpenDKIM only looks at the "From" message header to
determine the sender.

from opendkim.conf(5):

>| SenderHeaders (dataset) Specifies an ordered list of header fields
>| that should be searched to determine the sender of a message.  This
>| is mainly used when verifying a message to determine the origin
>| domain, particularly for doing domain policy queries.  By default,
>| the  DKIM library's internal list is used, which consists solely of
>| the "From" header field.

Assuming that your mailman instance adds a "Sender" header that matches
the list-name (or a verpified version thereof) to outgoing messages,
adding something like:

SenderHeaders   Sender,From

to your opendkim.conf *should* resolve the problem.
FWIW, making that config change resolved the issue in my case. YMMV.

-- 
Joe Sniderman 
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Ralf Hildebrandt]

> > Why such mail would not be DKIM signed by Postfix when mail submitted
> > via the Postfix sendmail command is DKIM signed by Postfix probably
> > has to do with the Postfix/opendkim configuration and is not something
> > I can answer offhand.
> >
> 
> If you think of anything, please let me know. I have been reading all the
> DKIM related posts I can find, both on this list and other places.

Maybe it's just a smtpd_milter and thus not enabled for sendmail

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
http://www.charite.de  Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Mark Sapiro]

David wrote:
>
>For a mailing list, would I have to expand my SigningTable in any way? My
>opendkim SigningTable currently only has an entry for
>*@list.example.com(which is associated with list._
>domainkey.example.com).
>
>But /var/log/mail.log shows a lot of entries like this:
>
>no signing table match for [some member of the list]
>>
>
>So I think signing doesn't take place for messages passing through the list
>because of the way I set up my SigningTable. But I didn't find any specific
>info on setting up a SigningTable for a mailing list.
>
>The mail log file also shows entries like this:
>
>May 12 21:45:42 localhost opendkim[20976]: 55A4C122C5: DKIM-Signature
>> header added
>>
>
>Although when I manually inspect emails I receive via the list from other
>users they are never DKIM signed. (My own messages are signed -- and I
>certainly match the signing table. But I can't match the log entries up to
>individual users or to list activity, so far; therefore, a number of things
>are still unclear.)
>
>(Similarly, my trusted hosts table is limited to my own Mailman/Postfix
>server. But I can't imagine it would be wise to change that.)


It seems you have the appropriate information to diagnose your issue,
but you are asking the wrong list.

Try 


-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[David]

On Sun, May 13, 2012 at 12:51 AM, Mark Sapiro  wrote:

> David wrote:
> >
> >I have DKIM implemented with opendkim and Postfix and messages sent out
> via
> >sendmail are signed properly.
> >
> >However, messages sent out to the list's users by Mailman are not DKIM
> >signed. Any suggestions?
>
>
> Is Mailman sending outgoing mail via your local Postfix.
>

Yes.


> Why such mail would not be DKIM signed by Postfix when mail submitted
> via the Postfix sendmail command is DKIM signed by Postfix probably
> has to do with the Postfix/opendkim configuration and is not something
> I can answer offhand.
>

If you think of anything, please let me know. I have been reading all the
DKIM related posts I can find, both on this list and other places.

For a mailing list, would I have to expand my SigningTable in any way? My
opendkim SigningTable currently only has an entry for
*@list.example.com(which is associated with list._
domainkey.example.com).

But /var/log/mail.log shows a lot of entries like this:

no signing table match for [some member of the list]
>

So I think signing doesn't take place for messages passing through the list
because of the way I set up my SigningTable. But I didn't find any specific
info on setting up a SigningTable for a mailing list.

The mail log file also shows entries like this:

May 12 21:45:42 localhost opendkim[20976]: 55A4C122C5: DKIM-Signature
> header added
>

Although when I manually inspect emails I receive via the list from other
users they are never DKIM signed. (My own messages are signed -- and I
certainly match the signing table. But I can't match the log entries up to
individual users or to list activity, so far; therefore, a number of things
are still unclear.)

(Similarly, my trusted hosts table is limited to my own Mailman/Postfix
server. But I can't imagine it would be wise to change that.)
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Mark Sapiro]

David wrote:
>
>I have DKIM implemented with opendkim and Postfix and messages sent out via
>sendmail are signed properly.
>
>However, messages sent out to the list's users by Mailman are not DKIM
>signed. Any suggestions?


Is Mailman sending outgoing mail via your local Postfix.

These headers from yor post at


Received: from myhost.hostingprovider.com (localhost [127.0.0.1])
   by localhost (Postfix) with ESMTP id E9CA1123AB;
   Wed,  9 May 2012 21:43:23 + (UTC)
X-Original-To: list at lists.example.com
Delivered-To: list at lists.example.com
Received: from fmailhost01.isp.att.net (fmailhost01.isp.att.net
 [204.127.217.101]) by localhost (Postfix) with ESMTP id 1D84D123A4
 for ; Wed,  9 May 2012 20:52:06 + (UTC)

indicate that it is.

Why such mail would not be DKIM signed by Postfix when mail submitted
via the Postfix sendmail command is DKIM signed by Postfix probably
has to do with the Postfix/opendkim configuration and is not something
I can answer offhand.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[David]

On Thu, May 10, 2012 at 4:28 PM, Mark Sapiro  wrote:

>
> DKIM signing is normally done in an outgoing MTA. SPF and reverse DNS
> are DNS things, not Mailman.
>
> In general, best practices for Mailman servers are the same as best
> practices for sending mail in general.
>
> Mailman does have the ability to remove DKIM signatures from incoming
> mail where Mailman might break these signatures by, e.g., prefixing
> Subject: headers and/or adding list header or footer information to
> message bodies, but this is controversial. Also, DKIM signing of
> outgoing list mail is controversial because by doing so, you are
> saying that your server vouches for the legitimacy of this mail when,
> in fact, it may be spam that made it through your list.
>
> Read some of the hits returned by
> .
>
>
Thanks for the info and the search link. Interesting reading (some of it,
anyway). In regard to the controversial aspect of DKIM signing of outgoing
list mail, we moderate all messages, so I'm not too concerned about that
part.

I have DKIM implemented with opendkim and Postfix and messages sent out via
sendmail are signed properly.

However, messages sent out to the list's users by Mailman are not DKIM
signed. Any suggestions?
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[David]

On Fri, May 11, 2012 at 6:06 AM, Attila Kinali  wrote:

>
> Getting to >99.9% delivery for a mailinglist is not difficult. Unless you
> use it to manage your newsletter distribution.
>
> The trick is: Do not force people onto your mailinglist. Make it a list
> were most people are tech-savy (helps a lot to keep problems down and
> if there are any, you get usefull reports) and make sure nobody is using
> yahoo.
>

Haha. Our demographics are older people who are not tech savvy (some don't
even know what a right mouse button click does) and a lot of them still
like Yahoo.
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Attila Kinali]

On Wed, 9 May 2012 16:01:57 -0400
David  wrote:

> It seems to me that Mailman provides at least some of the intelligence (via
> logs) that 37Signals custom developed on top of Postfix. Am I right? The
> core suggestions seem to be universalL SPF records, DKIM signing, reverse
> DNS entries, etc.. (And, btw, I don't yet know how to implement any of
> those things except SPF records.)

Not any more than others have done years ago.
Getting to >99.9% delivery for a mailinglist is not difficult. Unless you
use it to manage your newsletter distribution.

The trick is: Do not force people onto your mailinglist. Make it a list
were most people are tech-savy (helps a lot to keep problems down and
if there are any, you get usefull reports) and make sure nobody is using yahoo.
Oh and weed out dead addresses early... For any mailinglist that runs more
than a couple of weeks, you'll have somewhere between 0.1% and 1% dead
addresses per month.

The rest is really just configuring your MTA correctly and keeping an
eye on it.

Attila Kinali
-- 
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Ralf Hildebrandt]

* Geoff Shang :
> On Fri, 11 May 2012, Ralf Hildebrandt wrote:
> 
> >On the other hand we're getting spam reports for list mails (not
> >spam!) our users sent to a list. But since it's not spam we cannot
> >actually do anything about those mails while the LIST ADMIN could
> >easily unsubscribe the people reporting the spam.
> 
> Except the list admin may not know about this.

Yes, he doesn't know, since he's never notified. We're getting the
feedback-loop mails.

> Some people are just too lazy to unsubscribe from a list they
> double-opted into and report the mail as spam.

Indeed!
 
> I had a situation where the organisation I was working for was having
> all mail sent from its server being completely blocked by a large
> American ISP, all on the back of one person's spam reports.

Same here.

> They wouldn't even tell us what the address was.  Fortunately I was
> able to figure out the address and the list from the headers of a
> message and remove the person in question.  I'm not sure that I'dve
> been able to do this with a Mailman message, they were using inferior
> (IMHO) list software then.
> 
> The only way we could avoid this happening again was to subscribe to
> their feedback loop.  Then we would receive the spam reports instead
> of them being immediately acted upon, under the understanding that we
> would act on them instead.

Exactly. 

> Of course, everyone has their own feedback loop, and if you care
> about getting mail through to big providers, you'll probably need to
> subscribe to all their feedback loops.

Oh yes.

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
http://www.charite.de  Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Geoff Shang]

On Fri, 11 May 2012, Ralf Hildebrandt wrote:


On the other hand we're getting spam reports for list mails (not
spam!) our users sent to a list. But since it's not spam we cannot
actually do anything about those mails while the LIST ADMIN could
easily unsubscribe the people reporting the spam.


Except the list admin may not know about this.  Some people are just too 
lazy to unsubscribe from a list they double-opted into and report the mail 
as spam.


I had a situation where the organisation I was working for was having all 
mail sent from its server being completely blocked by a large American 
ISP, all on the back of one person's spam reports.  They wouldn't even 
tell us what the address was.  Fortunately I was able to figure out the 
address and the list from the headers of a message and remove the person 
in question.  I'm not sure that I'dve been able to do this with a Mailman 
message, they were using inferior (IMHO) list software then.


The only way we could avoid this happening again was to subscribe to their 
feedback loop.  Then we would receive the spam reports instead of them 
being immediately acted upon, under the understanding that we would act on 
them instead.


Of course, everyone has their own feedback loop, and if you care about 
getting mail through to big providers, you'll probably need to subscribe 
to all their feedback loops.


A good page with info on this and other issues is 
http://www.spamhaus.org/faq/section/ISP%20Spam%20Issues


HTH,
Geoff.

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Ralf Hildebrandt]

> Mailman does have the ability to remove DKIM signatures from incoming
> mail where Mailman might break these signatures by, e.g., prefixing
> Subject: headers and/or adding list header or footer information to
> message bodies, but this is controversial. Also, DKIM signing of
> outgoing list mail is controversial because by doing so, you are
> saying that your server vouches for the legitimacy of this mail when,
> in fact, it may be spam that made it through your list.

On the other hand we're getting spam reports for list mails (not
spam!) our users sent to a list. But since it's not spam we cannot
actually do anything about those mails while the LIST ADMIN could
easily unsubscribe the people reporting the spam.

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
http://www.charite.de  Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Giving away the secrets of 99.3% email delivery

[Mark Sapiro]

David wrote:
>
>The 37Signals article caught my attention. I would enjoy knowing others's
>thoughts about how to apply these (or other) suggestions to Mailman.
>
>It seems to me that Mailman provides at least some of the intelligence (via
>logs) that 37Signals custom developed on top of Postfix. Am I right? The
>core suggestions seem to be universalL SPF records, DKIM signing, reverse
>DNS entries, etc.. (And, btw, I don't yet know how to implement any of
>those things except SPF records.)


DKIM signing is normally done in an outgoing MTA. SPF and reverse DNS
are DNS things, not Mailman.

In general, best practices for Mailman servers are the same as best
practices for sending mail in general.

Mailman does have the ability to remove DKIM signatures from incoming
mail where Mailman might break these signatures by, e.g., prefixing
Subject: headers and/or adding list header or footer information to
message bodies, but this is controversial. Also, DKIM signing of
outgoing list mail is controversial because by doing so, you are
saying that your server vouches for the legitimacy of this mail when,
in fact, it may be spam that made it through your list.

Read some of the hits returned by
.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Giving away the secrets of 99.3% email delivery

[David]

Is this an appropriate place to discuss the broader topic of how to best
use Mailman? Now that we have it running well, we would like to take
additional steps to ensure that the list's emails are delivered as well as
they can be.

The 37Signals article caught my attention. I would enjoy knowing others's
thoughts about how to apply these (or other) suggestions to Mailman.

It seems to me that Mailman provides at least some of the intelligence (via
logs) that 37Signals custom developed on top of Postfix. Am I right? The
core suggestions seem to be universalL SPF records, DKIM signing, reverse
DNS entries, etc.. (And, btw, I don't yet know how to implement any of
those things except SPF records.)

 Giving away the secrets of 99.3% email
delivery

We send a lot of mail for Basecamp ,
Highrise ,
Backpack,
and Campfire  (and some for
Sortfolio , the Jobs Board ,
Writeboard , and Tadalist ). One of
the most frequently asked questions we get is about how we handle mail
delivery and ensure that emails are making it to people’s inboxes.
Some statistics

First, some numbers to give a little context to what we mean by “a lot” of
email. In the last 7 days, we’ve sent just shy of 16 million emails, with
approximately 99.3% of them being accepted by the remote mail server.

Email delivery rate is a little bit of a tough thing to benchmark, but by
most accounts we’re doing pretty well at those rates (for comparison, the
tiny fraction of email that we use a third party for has had between a
96.9% and 98.6% delivery rate for our most recent mailings).
How we send email

We send almost all of our outgoing email from our own servers in our data
center located just outside of Chicago. We use Campaign
Monitorfor our mailing lists, but all of
the email that’s generated by our
applications is sent from our own servers.

We run three mail-relay servers running Postfix that take mail from our
application and jobs servers and queue it for delivery to tens of thousands
of remote mail servers, sending from about 15 unique IP addresses.
How we monitor delivery

We have developed some instrumentation so we can monitor how we are doing
on getting messages to our users’ inbox. Our applications tag each outgoing
message with a unique header with a hashed value that gets recorded by the
application before the message is sent.

To gather delivery information, we run a script that tails the Postfix logs
and extracts the delivery time and status for each piece of mail, including
any error message received from the receiving mail server, and links it
back to the hash the application stored. We store this information for 30
days so that our fantastic support team  is
able to help customers track down why they may not have received an email.

We also send these statistics to our statsd server so they can be reported
through our metrics dashboard. This “live” and historical information can
then be used by our operations team to check how we’re doing on aggregate
mail delivery for each application.
Why run your own mail servers?

Over the last few years, at least a dozen services that specialize in
sending email have popped up, ranging from the bare-bones to the
full-service. Despite all these “email as a service” startups we’ve kept
our mail delivery in-house, for a couple of reasons:

   - *We don’t know anyone who could do it better.* With a 99.3% delivery
   rate, we haven’t found a third party provider that actually does better in
   a way they’re willing to guarantee.
   - *Setup hassle* Most of the third party services require that you
   verify each address that sends email by clicking a link that gets sent to
   that address. We send email from thousands and thousands of email addresses
   for our products, and the hassle of automatically registering and
   confirming them is significant. Automating the process still introduces
   unnecessary delivery delays.

Given all this, why should we pay someone tens of thousands of dollars to
do it? We shouldn’t, and we don’t.

*Read more about how we keep delivery rates high after the jump…*
How we keep our mail delivery rates up

Lets be honest from the get-go. Mail delivery is more of an art than a
science. We’ve found that even when you “play by the rules”, there’s still
times when a major provider will reject all your mail without notice.
Usually it takes a couple emails to to the providers abuse address, and
things get resolved. In spite of these “out of our control” issues, we’ve
found a few things help us keep delivery rates up:

   1. *Constantly monitor spam
blacklists