Re: [mailop] deactivation of hard bounces

[Benjamin BILLON]

Tricky; we have a similar case, but not specifically B2B.
The sender is complaining that a bunch of addresses flagged as hard are in fact 
not bouncing when they test them.
The samples they provided is mostly Outlook.com, and a bit of Gmail. So they're 
most probably complaining that what we flagged hard bounces are now 
Outlook.com's spamtraps.
(I can't really tell about Gmail though).
We could tell more by a) checking the spamtrap count on SNDS (but do we really 
want to?) and b) checking if there's any reaction from these addresses (but 
spamtraps can also "react" if they want to).

Sure, mistakes happen, both on the receiver's and on the sender's side. But for 
us the balance benefit/risk isn't worth it. Senders complaining about a few 
false-positive hard bounces probably should be spending their time and energy 
on data collection and practices instead.

So we have to de-hard a few addresses every few years, when one ISP messes up. 
We can live with that.

--
Benjamin

From: mailop  On Behalf Of Marco Franceschetti via 
mailop
Sent: lundi 4 mars 2019 10:16
To: Maarten Oelering 
Cc: mailop@mailop.org
Subject: Re: [mailop] deactivation of hard bounces

Hi Maarten

By one specific customer, whose lists are more b2b oriented to be honest, we 
enountered a false positive rate of abount 7%.
This customer regularly sends to us small lists of addresses to be reactivated 
– and I must say, these do not bounce.
So, I think a further investigation on this matter is worth.

Sure, we use text, enhanced status code and status code to classify the bounces 
in our bounce rule management process.
It the rules don’t match, we classify the bounce as “unknown” and we examinate 
the unknown bounce regularly to do some fine tuning.

Kind regards
Marco


From: Maarten Oelering mailto:maar...@postmastery.com>>
Sent: mercoledì 27 febbraio 2019 22:02
To: Marco Franceschetti 
mailto:marco.francesche...@contactlab.com>>
Cc: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: Re: [mailop] deactivation of hard bounces

Hi Marco,

I am curious what false positives you encountered.

We suggest to classify bounces using multiple features, the text, the enhanced 
status code, and the status code. If the bounce is clearly an invalid address, 
then remove it after the first bounce. For example when the text contains 
“mailbox” or a synonym, and “unknown” or a synonym. Bounces which are 
ambiguous, or with inconsistent features should be treated as soft bounce.

Maarten
Postmastery

On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop 
mailto:mailop@mailop.org>> wrote:
Hello,

We at contactlab are considering a change in the deactivation of hard bounces.
Currently, we suppress not existing mailboxes at the first hit.

We are aware of a small percentage of false positives.

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, after sending 
to this address,
the mailbox is identified as non-existent; at the latest, however, this must 
occur after three hard
bounces".

We are evaluating to remove not existing mailboxes from the lists of our 
clients after the second hit instead of the first one.

Do you have any considerations, suggestions about this?

Marco


Marco Franceschetti
Head of Deliverability | ContactLab
marco.francesche...@contactlab.com<mailto:marco.francesche...@contactlab.com>
Via Natale Battaglia, 12 | 
Milano<https://maps.google.com/?q=Via+Natale+Battaglia,+12+%7C+Milano&entry=gmail&source=g>
contactlab.com/it<http://contactlab.com/it>

___
mailop mailing list
mailop@mailop.org<mailto: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] deactivation of hard bounces

[Marco Franceschetti via mailop]

Hi Maarten

By one specific customer, whose lists are more b2b oriented to be honest, we 
enountered a false positive rate of abount 7%.
This customer regularly sends to us small lists of addresses to be reactivated 
– and I must say, these do not bounce.
So, I think a further investigation on this matter is worth.

Sure, we use text, enhanced status code and status code to classify the bounces 
in our bounce rule management process.
It the rules don’t match, we classify the bounce as “unknown” and we examinate 
the unknown bounce regularly to do some fine tuning.

Kind regards
Marco


From: Maarten Oelering 
Sent: mercoledì 27 febbraio 2019 22:02
To: Marco Franceschetti 
Cc: mailop@mailop.org
Subject: Re: [mailop] deactivation of hard bounces

Hi Marco,

I am curious what false positives you encountered.

We suggest to classify bounces using multiple features, the text, the enhanced 
status code, and the status code. If the bounce is clearly an invalid address, 
then remove it after the first bounce. For example when the text contains 
“mailbox” or a synonym, and “unknown” or a synonym. Bounces which are 
ambiguous, or with inconsistent features should be treated as soft bounce.

Maarten
Postmastery

On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop 
mailto:mailop@mailop.org>> wrote:
Hello,

We at contactlab are considering a change in the deactivation of hard bounces.
Currently, we suppress not existing mailboxes at the first hit.

We are aware of a small percentage of false positives.

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, after sending 
to this address,
the mailbox is identified as non-existent; at the latest, however, this must 
occur after three hard
bounces".

We are evaluating to remove not existing mailboxes from the lists of our 
clients after the second hit instead of the first one.

Do you have any considerations, suggestions about this?

Marco


Marco Franceschetti
Head of Deliverability | ContactLab
marco.francesche...@contactlab.com<mailto:marco.francesche...@contactlab.com>
Via Natale Battaglia, 12 | 
Milano<https://maps.google.com/?q=Via+Natale+Battaglia,+12+%7C+Milano&entry=gmail&source=g>
contactlab.com/it<http://contactlab.com/it>

___
mailop mailing list
mailop@mailop.org<mailto: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] deactivation of hard bounces

[Marco Franceschetti via mailop]

Good morning

I want to say a great "thank you" to all of you for the precious suggestions. 
All of your contributions will help us in the evaluation of a possible approach 
on this matter. 

Regards
Marco 

-Original Message-
From: mailop  On Behalf Of Bill Cole
Sent: mercoledì 27 febbraio 2019 18:27
To: Marco Franceschetti via mailop 
Subject: Re: [mailop] deactivation of hard bounces

On 27 Feb 2019, at 11:16, Marco Franceschetti via mailop wrote:

> Hello,
>
> We at contactlab are considering a change in the deactivation of hard 
> bounces.
> Currently, we suppress not existing mailboxes at the first hit.
>
> We are aware of a small percentage of false positives.
>
> Recent admissions criteria for Certified Senders states:
> "The CSA sender must take email addresses from mailing lists, if, 
> after sending to this address, the mailbox is identified as 
> non-existent; at the latest, however, this must occur after three hard 
> bounces".
>
> We are evaluating to remove not existing mailboxes from the lists of 
> our clients after the second hit instead of the first one.
>
> Do you have any considerations, suggestions about this?

There are subtle but important distinctions between types of "hard bounce" 
which you should take into account. ANY 5xy reply in SMTP (or asynchronous DSN 
message citing a 5xy reply) should be considered a "hard bounce." However, 
there are specific basic and enhanced SMTP reply codes which are direct 
explicit statements that an address is non-existent which should be honored 
immediately rather than taken as possibly mistaken and retested later with a 
different message. For example, a 550 reply to RCPT (or either stage of DATA, 
if there's only one accepted RCPT)  without any enhanced status code should 
ALWAYS be treated as an indication of a non-existent address, as should 550 
followed by any 5.1.x enhanced status code. It is debatable how other 5xy + 
5.x.y combinations at various stages should affect sending a different message 
at a later time to the same address, but as every modern SMTP RFC has made 
clear: ANY 5xy reply should be considered a "hard bounce" for the specific 
transaction being tried. That means you must not try to resend the same message 
to the same address in any way: 
not 5 minutes later, not through a different outbound IP or to a secondary MX, 
not with a different envelope sender address, NOT AT ALL.

It is good practice to remove an address from a list after just one hard bounce 
of the subset that clearly indicate that an address does not exist or after 
consecutive hard bounces (i.e. for different messages) with less certain 
meanings. Whether you make 2 or 3 your limit for hard bounce codes that might 
indicate problems other than address non-existence is unlikely to make much 
difference.


--
Bill Cole
b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many 
*@billmail.scconsult.com addresses) Available For Hire: 
https://linkedin.com/in/billcole

___
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] deactivation of hard bounces

[Brandon Long via mailop]

Yeah, we've run into all sorts of problems with the automatic bounce
handling for Google Groups that way
as well, there are a lot of bounce messages where you have to read them,
and they're often in languages beyond
English (and not always ascii, or munged because the should be ascii and
something breaks inbetween) or whatever.
And that's on top of services with outages giving out "unknown user"
temporarily to
virtually everyone.  I think the current groups setup is 3 probes after
that to verify.  Probes used to be an actual
specific test message, but are now just special handling of the next
messages on the group, so they may could be very
spread depending on the group traffic.

We found a lot of places where the probe messages would get through, but
the actual group messages would be
rejected for various content based reasons, hence the change.

Automated bounce handling is kind of a mess.

And I recognize the benefits of bounces being in the user's language (we
did a bunch of work to do that when we figured out
certain countries always marked their english bounce messages as spam), the
whole thing just adds to the mess.

Brandon

On Thu, Feb 28, 2019 at 6:42 AM Al Iverson  wrote:

> It can be tough to square the "how dare you ever do this" responses
> from a couple of big ISPs versus the personal and direct experience of
> other big ISPs having meltdown scenarios where they give false
> positive "user unknown" bounces for periods of time. Been there, done
> that.
>
> Truth be told, everybody else's stuff breaks sometimes. We do
> implement a counter-based bounce mechanism here for that very reason.
> We also have a domain list where we can opt-domains out of this and
> say that we "trust" the user unknown bounces from those domains, for
> those who might get unhappy about that.
>
> An ESP who wants to make sure because they've been burned before is
> not necessarily the devil here, folks.
>
> Regards,
> Al Iverson
>
> On Thu, Feb 28, 2019 at 9:30 AM Arne Allisat 
> wrote:
> >
> > We (web.de, GMX, mail.com) are clear in our response.
> >
> > We state if recipient mailbox either not exists "5xy Requested action
> not taken: mailbox unavailable“ or is out of storage "5xy Requested mail
> action aborted: exceeded storage allocation, Quota exceeded“.
> > If you do not stop sending to unavailable mailboxes we’ll block you
> sooner than later.
> >
> > We also state this in our mail policy:
> https://postmaster.web.de/en/email-policy
> >
> > Best regards
> > Arne
> >
> >
> > Arne Allisat
> >
> > Head of Mail Application Security
> > Product Management Applications
> >
> > 1&1 Mail & Media GmbH | Brauerstraße 48 | 76135 Karlsruhe | Germany
> > E-Mail: arne.alli...@1und1.de | Web: www.1und1.de
> >
> >
> >
> > Am 27.02.2019 um 22:01 schrieb Maarten Oelering  >:
> >
> > Hi Marco,
> >
> > I am curious what false positives you encountered.
> >
> > We suggest to classify bounces using multiple features, the text, the
> enhanced status code, and the status code. If the bounce is clearly an
> invalid address, then remove it after the first bounce. For example when
> the text contains “mailbox” or a synonym, and “unknown” or a synonym.
> Bounces which are ambiguous, or with inconsistent features should be
> treated as soft bounce.
> >
> > Maarten
> > Postmastery
> >
> > On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop <
> mailop@mailop.org> wrote:
> >>
> >> Hello,
> >>
> >> We at contactlab are considering a change in the deactivation of hard
> bounces.
> >> Currently, we suppress not existing mailboxes at the first hit.
> >>
> >> We are aware of a small percentage of false positives.
> >>
> >> Recent admissions criteria for Certified Senders states:
> >> "The CSA sender must take email addresses from mailing lists, if, after
> sending to this address,
> >> the mailbox is identified as non-existent; at the latest, however, this
> must occur after three hard
> >> bounces".
> >>
> >> We are evaluating to remove not existing mailboxes from the lists of
> our clients after the second hit instead of the first one.
> >>
> >> Do you have any considerations, suggestions about this?
> >>
> >> Marco
> >>
> >>
> >> Marco Franceschetti
> >> Head of Deliverability | ContactLab
> >> marco.francesche...@contactlab.com
> >> Via Natale Battaglia, 12 | Milano
> >> contactlab.com/it
> >>
> >> ___
> >> 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
> >
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
> --
> al iverson // wombatmail // miami
> http://www.aliverson.com
> http://www.spamresource.com
>
> __

Re: [mailop] deactivation of hard bounces

[Al Iverson]

It can be tough to square the "how dare you ever do this" responses
from a couple of big ISPs versus the personal and direct experience of
other big ISPs having meltdown scenarios where they give false
positive "user unknown" bounces for periods of time. Been there, done
that.

Truth be told, everybody else's stuff breaks sometimes. We do
implement a counter-based bounce mechanism here for that very reason.
We also have a domain list where we can opt-domains out of this and
say that we "trust" the user unknown bounces from those domains, for
those who might get unhappy about that.

An ESP who wants to make sure because they've been burned before is
not necessarily the devil here, folks.

Regards,
Al Iverson

On Thu, Feb 28, 2019 at 9:30 AM Arne Allisat  wrote:
>
> We (web.de, GMX, mail.com) are clear in our response.
>
> We state if recipient mailbox either not exists "5xy Requested action not 
> taken: mailbox unavailable“ or is out of storage "5xy Requested mail action 
> aborted: exceeded storage allocation, Quota exceeded“.
> If you do not stop sending to unavailable mailboxes we’ll block you sooner 
> than later.
>
> We also state this in our mail policy: 
> https://postmaster.web.de/en/email-policy
>
> Best regards
> Arne
>
>
> Arne Allisat
>
> Head of Mail Application Security
> Product Management Applications
>
> 1&1 Mail & Media GmbH | Brauerstraße 48 | 76135 Karlsruhe | Germany
> E-Mail: arne.alli...@1und1.de | Web: www.1und1.de
>
>
>
> Am 27.02.2019 um 22:01 schrieb Maarten Oelering :
>
> Hi Marco,
>
> I am curious what false positives you encountered.
>
> We suggest to classify bounces using multiple features, the text, the 
> enhanced status code, and the status code. If the bounce is clearly an 
> invalid address, then remove it after the first bounce. For example when the 
> text contains “mailbox” or a synonym, and “unknown” or a synonym. Bounces 
> which are ambiguous, or with inconsistent features should be treated as soft 
> bounce.
>
> Maarten
> Postmastery
>
> On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop 
>  wrote:
>>
>> Hello,
>>
>> We at contactlab are considering a change in the deactivation of hard 
>> bounces.
>> Currently, we suppress not existing mailboxes at the first hit.
>>
>> We are aware of a small percentage of false positives.
>>
>> Recent admissions criteria for Certified Senders states:
>> "The CSA sender must take email addresses from mailing lists, if, after 
>> sending to this address,
>> the mailbox is identified as non-existent; at the latest, however, this must 
>> occur after three hard
>> bounces".
>>
>> We are evaluating to remove not existing mailboxes from the lists of our 
>> clients after the second hit instead of the first one.
>>
>> Do you have any considerations, suggestions about this?
>>
>> Marco
>>
>>
>> Marco Franceschetti
>> Head of Deliverability | ContactLab
>> marco.francesche...@contactlab.com
>> Via Natale Battaglia, 12 | Milano
>> contactlab.com/it
>>
>> ___
>> 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
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



-- 
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com

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

Re: [mailop] deactivation of hard bounces

[Arne Allisat]

We (web.de, GMX, mail.com) are clear in our 
response.

We state if recipient mailbox either not exists "5xy Requested action not 
taken: mailbox unavailable“ or is out of storage "5xy Requested mail action 
aborted: exceeded storage allocation, Quota exceeded“.
If you do not stop sending to unavailable mailboxes we’ll block you sooner than 
later.

We also state this in our mail policy: https://postmaster.web.de/en/email-policy

Best regards
Arne


Arne Allisat
Head of Mail Application Security
Product Management Applications
1&1 Mail & Media GmbH | Brauerstraße 48 | 76135 Karlsruhe | Germany
E-Mail: arne.alli...@1und1.de | Web: 
www.1und1.de


Am 27.02.2019 um 22:01 schrieb Maarten Oelering :

Hi Marco,

I am curious what false positives you encountered.

We suggest to classify bounces using multiple features, the text, the enhanced 
status code, and the status code. If the bounce is clearly an invalid address, 
then remove it after the first bounce. For example when the text contains 
“mailbox” or a synonym, and “unknown” or a synonym. Bounces which are 
ambiguous, or with inconsistent features should be treated as soft bounce.

Maarten
Postmastery

On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop 
mailto:mailop@mailop.org>> wrote:
Hello,

We at contactlab are considering a change in the deactivation of hard bounces.
Currently, we suppress not existing mailboxes at the first hit.

We are aware of a small percentage of false positives.

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, after sending 
to this address,
the mailbox is identified as non-existent; at the latest, however, this must 
occur after three hard
bounces".

We are evaluating to remove not existing mailboxes from the lists of our 
clients after the second hit instead of the first one.

Do you have any considerations, suggestions about this?

Marco


Marco Franceschetti
Head of Deliverability | ContactLab
marco.francesche...@contactlab.com
Via Natale Battaglia, 12 | 
Milano
contactlab.com/it

___
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

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

Re: [mailop] deactivation of hard bounces

[Maarten Oelering]

Hi Marco,

I am curious what false positives you encountered.

We suggest to classify bounces using multiple features, the text, the
enhanced status code, and the status code. If the bounce is clearly an
invalid address, then remove it after the first bounce. For example when
the text contains “mailbox” or a synonym, and “unknown” or a synonym.
Bounces which are ambiguous, or with inconsistent features should be
treated as soft bounce.

Maarten
Postmastery

On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop <
mailop@mailop.org> wrote:

> Hello,
>
> We at contactlab are considering a change in the deactivation of hard
> bounces.
> Currently, we suppress not existing mailboxes at the first hit.
>
> We are aware of a small percentage of false positives.
>
> Recent admissions criteria for Certified Senders states:
> "The CSA sender must take email addresses from mailing lists, if, after
> sending to this address,
> the mailbox is identified as non-existent; at the latest, however, this
> must occur after three hard
> bounces".
>
> We are evaluating to remove not existing mailboxes from the lists of our
> clients after the second hit instead of the first one.
>
> Do you have any considerations, suggestions about this?
>
> Marco
>
>
> Marco Franceschetti
> Head of Deliverability | ContactLab
> marco.francesche...@contactlab.com
> Via Natale Battaglia, 12 | Milano
> 
> contactlab.com/it
>
> ___
> 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] deactivation of hard bounces

[Michael Wise via mailop]

Some of us have to clean up the stick.
Messy work.

Aloha,
Michael.
-- 
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting Tool ?

-Original Message-
From: mailop  On Behalf Of Bill Cole
Sent: Wednesday, February 27, 2019 10:57 AM
To: Michael Wise via mailop 
Subject: Re: [mailop] deactivation of hard bounces

On 27 Feb 2019, at 13:34, Michael Wise via mailop wrote:

> If you ignore hard bounces on the Hotmail infrastructure...'
> There will come a day, possibly sooner than you'd like, when the 
> system will blacklist you, and you'll find it hard to get mitigated.
>
> All automatic.

I sincerely hope that this day comes soon, given wisely subtle definitions of 
"hard bounces" and "ignore." A well-intentioned drunk 800-lb. gorilla with a 
big stick may have the downsides of any drunk gorilla, but that big stick can 
come in handy...

(e.g. hopefully Clippy or Bob or whoever won't get grumpy if after a
"552 4.0.0 Bad disk, try again later" at the end-of-DATA for a 2MB message with 
10 RCPTs, a sender comes back to try a new 10KB message for each of them on 
their own session tomorrow...)


--
Bill Cole
b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many 
*@billmail.scconsult.com addresses) Available For Hire: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkedin.com%2Fin%2Fbillcole&data=02%7C01%7Cmichael.wise%40microsoft.com%7C3402de214b8c4c30314808d69ce61f80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636868909520989179&sdata=hLTprAuMKYPq1Hc%2B5JsqqI%2FhqTXV9rKak9sEjs2O1wA%3D&reserved=0

___
mailop mailing list
mailop@mailop.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailop&data=02%7C01%7Cmichael.wise%40microsoft.com%7C3402de214b8c4c30314808d69ce61f80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636868909520989179&sdata=gAsDVLZXgW4w1KODmpGtVBdd9fHiTkHQA6DuGDt2uYc%3D&reserved=0
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] deactivation of hard bounces

[Bill Cole]

On 27 Feb 2019, at 13:34, Michael Wise via mailop wrote:


If you ignore hard bounces on the Hotmail infrastructure...'
There will come a day, possibly sooner than you'd like, when the 
system will blacklist you, and you'll find it hard to get mitigated.


All automatic.


I sincerely hope that this day comes soon, given wisely subtle 
definitions of "hard bounces" and "ignore." A well-intentioned drunk 
800-lb. gorilla with a big stick may have the downsides of any drunk 
gorilla, but that big stick can come in handy...


(e.g. hopefully Clippy or Bob or whoever won't get grumpy if after a 
"552 4.0.0 Bad disk, try again later" at the end-of-DATA for a 2MB 
message with 10 RCPTs, a sender comes back to try a new 10KB message for 
each of them on their own session tomorrow...)



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

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

Re: [mailop] deactivation of hard bounces

[Tobias Herkula]

They say you could do this and the max is 3, they do not they you have to wait 
until the third one. That’s a big difference!

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)


Von: mailop  im Auftrag von Marco Franceschetti via 
mailop 
Gesendet: Mittwoch, Februar 27, 2019 6:26 PM
An: mailop@mailop.org
Betreff: [mailop] deactivation of hard bounces

Hello,

We at contactlab are considering a change in the deactivation of hard bounces.
Currently, we suppress not existing mailboxes at the first hit.

We are aware of a small percentage of false positives.

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, after sending 
to this address,
the mailbox is identified as non-existent; at the latest, however, this must 
occur after three hard
bounces".

We are evaluating to remove not existing mailboxes from the lists of our 
clients after the second hit instead of the first one.

Do you have any considerations, suggestions about this?

Marco


Marco Franceschetti
Head of Deliverability | ContactLab
marco.francesche...@contactlab.com
Via Natale Battaglia, 12 | Milano
contactlab.com/it

___
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] deactivation of hard bounces

[Michael Wise via mailop]

If you ignore hard bounces on the Hotmail infrastructure...'
There will come a day, possibly sooner than you'd like, when the system will 
blacklist you, and you'll find it hard to get mitigated.

All automatic.

Aloha,
Michael.
-- 
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting Tool ?

-Original Message-
From: mailop  On Behalf Of Bill Cole
Sent: Wednesday, February 27, 2019 10:25 AM
To: mailop@mailop.org
Subject: Re: [mailop] deactivation of hard bounces

On 27 Feb 2019, at 12:36, Michael Peddemors wrote:

> On 2019-02-27 9:27 a.m., Bill Cole wrote:
>> However, there are specific basic and enhanced SMTP reply codes which 
>> are direct explicit statements that an address is non-existent which 
>> should be honored immediately rather than taken as possibly mistaken 
>> and retested later with a different message. For example, a 550 reply 
>> to RCPT (or either stage of DATA, if there's only one accepted RCPT) 
>> without any enhanced status code should ALWAYS be treated as an 
>> indication of a non-existent address, as should 550 followed by any 
>> 5.1.x enhanced status code.
>
> Hi Bill,
>
> Do remember, in spite of RFC's there also is the perspective by many 
> SMTP implementations or operators, to NOT reveal whether an email 
> address actually exists, vs whether the message is non-deliverable.
>
> Some implementations 'choose' to obfuscate the result to some extent 
> to help against dictionary attacks..

Which is a fine rationale for dropping addresses that chronically hard fail in 
any way after a very small number of those hard failures which may or may not 
indicate address non-existence (which I believe I did
advise.)

> Something to consider..

Perhaps, but not really very relevant to what I said.

If the receiving system explicitly says that an address is non-existent, a 
sender should believe them without re-testing. If they are explicitly asserting 
address non-existence when the real cause of rejection is the sender or the 
content, they are still telling the sender to stop mailing that address and 
that request should be honored.

If you act otherwise, you can (rightly) damage your own reputation.

For example, I have used dead addresses (which have been kicking back
'550 5.1.1' replies to RCPT for extended periods, sometimes  forever) as 
spammer canaries. The same unfamiliar sender hitting one twice in a short 
enough time will not be sending anything to any address on the same mail system 
for longer than the average ESP lifetime, absent manual intervention. This has 
been an effective and low-risk tactic for years.

--
Bill Cole
b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many 
*@billmail.scconsult.com addresses) Available For Hire: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkedin.com%2Fin%2Fbillcole&data=02%7C01%7Cmichael.wise%40microsoft.com%7C168feff578174dc2b8eb08d69ce1b5f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636868890575941249&sdata=QPC2u3Vi%2Bfr9l9GV%2Fd%2BOUL%2BzwddD3pF0RrG3wcuJmLU%3D&reserved=0

___
mailop mailing list
mailop@mailop.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailop&data=02%7C01%7Cmichael.wise%40microsoft.com%7C168feff578174dc2b8eb08d69ce1b5f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636868890575941249&sdata=4gMOX90tl%2BddHcMCduiYhhR%2BR8DMsEH6Bhm1nGbzVV0%3D&reserved=0
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] deactivation of hard bounces

[Bill Cole]

On 27 Feb 2019, at 12:36, Michael Peddemors wrote:


On 2019-02-27 9:27 a.m., Bill Cole wrote:
However, there are specific basic and enhanced SMTP reply codes which 
are direct explicit statements that an address is non-existent which 
should be honored immediately rather than taken as possibly mistaken 
and retested later with a different message. For example, a 550 reply 
to RCPT (or either stage of DATA, if there's only one accepted RCPT)  
without any enhanced status code should ALWAYS be treated as an 
indication of a non-existent address, as should 550 followed by any 
5.1.x enhanced status code.


Hi Bill,

Do remember, in spite of RFC's there also is the perspective by many 
SMTP implementations or operators, to NOT reveal whether an email 
address actually exists, vs whether the message is non-deliverable.


Some implementations 'choose' to obfuscate the result to some extent 
to help against dictionary attacks..


Which is a fine rationale for dropping addresses that chronically hard 
fail in any way after a very small number of those hard failures which 
may or may not indicate address non-existence (which I believe I did 
advise.)



Something to consider..


Perhaps, but not really very relevant to what I said.

If the receiving system explicitly says that an address is non-existent, 
a sender should believe them without re-testing. If they are explicitly 
asserting address non-existence when the real cause of rejection is the 
sender or the content, they are still telling the sender to stop mailing 
that address and that request should be honored.


If you act otherwise, you can (rightly) damage your own reputation.

For example, I have used dead addresses (which have been kicking back 
'550 5.1.1' replies to RCPT for extended periods, sometimes  forever) as 
spammer canaries. The same unfamiliar sender hitting one twice in a 
short enough time will not be sending anything to any address on the 
same mail system for longer than the average ESP lifetime, absent manual 
intervention. This has been an effective and low-risk tactic for years.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

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

Re: [mailop] deactivation of hard bounces

[Paul Kincaid-Smith]

Hi Marco,

Do you have a way to approach this scientifically with a well-structured 
experiment of your own? The data will tell the story for ContactLab’s unique 
mix of customers and receivers. 

Some sophisticated receivers are known to downgrade the reputation of senders 
who repeatedly attempt to deliver mail to non-existent addresses. They have 
(floating) thresholds, and those thresholds might be discoverable. Regardless, 
with the right inbox placement measurement tools, you should be able to observe 
an effect, if any. 

At the core, your question is about how to best serve (good) customers by 
balancing the upside of less-aggressive list pruning vs the downside of lower 
inbox placement at the subset of receivers who use redelivery signals in their 
reputation scoring. 

If the pain your customers are feeling is high, and enough of them are 
concerned that their lists are shrinking unnecessarily, there might be enough 
business justification to conduct such an experiment. 

Perhaps members of this list can share insights about which receivers are known 
to be particularly sensitive to senders who attempt just 1 or 2 additional 
retries after they issue a 5XX, and those who don’t.

(And here, I presume ContactLab won’t push retries past the CSA-imposed limit 
of 3.)

Paul Kincaid-Smith
EmailGrades

> On Feb 27, 2019, at 09:16, Marco Franceschetti via mailop  
> wrote:
> 
> Hello, 
> 
> We at contactlab are considering a change in the deactivation of hard 
> bounces. 
> Currently, we suppress not existing mailboxes at the first hit. 
> 
> We are aware of a small percentage of false positives. 
> 
> Recent admissions criteria for Certified Senders states:
> "The CSA sender must take email addresses from mailing lists, if, after 
> sending to this address,
> the mailbox is identified as non-existent; at the latest, however, this must 
> occur after three hard
> bounces".
> 
> We are evaluating to remove not existing mailboxes from the lists of our 
> clients after the second hit instead of the first one. 
> 
> Do you have any considerations, suggestions about this?
> 
> Marco 
> 
> 
> Marco Franceschetti
> Head of Deliverability | ContactLab
> marco.francesche...@contactlab.com
> Via Natale Battaglia, 12 | Milano
> contactlab.com/it 
> 
> ___
> 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] deactivation of hard bounces

[Michael Peddemors]

On 2019-02-27 9:27 a.m., Bill Cole wrote:
However, there are specific basic and enhanced SMTP reply codes which 
are direct explicit statements that an address is non-existent which 
should be honored immediately rather than taken as possibly mistaken and 
retested later with a different message. For example, a 550 reply to 
RCPT (or either stage of DATA, if there's only one accepted RCPT)  
without any enhanced status code should ALWAYS be treated as an 
indication of a non-existent address, as should 550 followed by any 
5.1.x enhanced status code.


Hi Bill,

Do remember, in spite of RFC's there also is the perspective by many 
SMTP implementations or operators, to NOT reveal whether an email 
address actually exists, vs whether the message is non-deliverable.


Some implementations 'choose' to obfuscate the result to some extent to 
help against dictionary attacks..


Something to consider..




--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

Re: [mailop] deactivation of hard bounces

[Bill Cole]

On 27 Feb 2019, at 11:16, Marco Franceschetti via mailop wrote:


Hello,

We at contactlab are considering a change in the deactivation of hard 
bounces.

Currently, we suppress not existing mailboxes at the first hit.

We are aware of a small percentage of false positives.

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, 
after sending to this address,
the mailbox is identified as non-existent; at the latest, however, 
this must occur after three hard

bounces".

We are evaluating to remove not existing mailboxes from the lists of 
our clients after the second hit instead of the first one.


Do you have any considerations, suggestions about this?


There are subtle but important distinctions between types of "hard 
bounce" which you should take into account. ANY 5xy reply in SMTP (or 
asynchronous DSN message citing a 5xy reply) should be considered a 
"hard bounce." However, there are specific basic and enhanced SMTP reply 
codes which are direct explicit statements that an address is 
non-existent which should be honored immediately rather than taken as 
possibly mistaken and retested later with a different message. For 
example, a 550 reply to RCPT (or either stage of DATA, if there's only 
one accepted RCPT)  without any enhanced status code should ALWAYS be 
treated as an indication of a non-existent address, as should 550 
followed by any 5.1.x enhanced status code. It is debatable how other 
5xy + 5.x.y combinations at various stages should affect sending a 
different message at a later time to the same address, but as every 
modern SMTP RFC has made clear: ANY 5xy reply should be considered a 
"hard bounce" for the specific transaction being tried. That means you 
must not try to resend the same message to the same address in any way: 
not 5 minutes later, not through a different outbound IP or to a 
secondary MX, not with a different envelope sender address, NOT AT ALL.


It is good practice to remove an address from a list after just one hard 
bounce of the subset that clearly indicate that an address does not 
exist or after consecutive hard bounces (i.e. for different messages) 
with less certain meanings. Whether you make 2 or 3 your limit for hard 
bounce codes that might indicate problems other than address 
non-existence is unlikely to make much difference.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

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

Re: [mailop] deactivation of hard bounces

[Michael Peddemors]

If you keep the retry far enough apart, the second hit could be okay, 
but you will run into cases of 'over quota' and temporary failures.


Technically, hard bounces take very little overhead on the receiving 
side, since the check is at SMTP layer, so unless you have a wide spread 
problem, eg a large number of stripped addresses, or fake 
sign-ups/mailbomb subscriptions, using three is a good number.


Suggestion?

* HARD BOUNCE (try again four (4) hours later)
* SECOND HARD BOUCE (try again 48 hours later)
* THIRD HARD BOUNCE (remove the address from ALL lists)

IMHO..

But, you SHOULD be careful as to the actual MAIL FROM being used..
Try to reflect the actual sender as much as possible (eg domain), that 
makes it easier for company specific white lists to allow the messages 
they want, especially when the service is a shared service.




On 2019-02-27 8:16 a.m., Marco Franceschetti via mailop wrote:

Hello,

We at contactlab are considering a change in the deactivation of hard bounces.
Currently, we suppress not existing mailboxes at the first hit.

We are aware of a small percentage of false positives.

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, after sending 
to this address,
the mailbox is identified as non-existent; at the latest, however, this must 
occur after three hard
bounces".

We are evaluating to remove not existing mailboxes from the lists of our 
clients after the second hit instead of the first one.

Do you have any considerations, suggestions about this?

Marco


Marco Franceschetti
Head of Deliverability | ContactLab
marco.francesche...@contactlab.com
Via Natale Battaglia, 12 | Milano
contactlab.com/it

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





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

[mailop] deactivation of hard bounces

[Marco Franceschetti via mailop]

Hello, 

We at contactlab are considering a change in the deactivation of hard bounces. 
Currently, we suppress not existing mailboxes at the first hit. 

We are aware of a small percentage of false positives. 

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, after sending 
to this address,
the mailbox is identified as non-existent; at the latest, however, this must 
occur after three hard
bounces".

We are evaluating to remove not existing mailboxes from the lists of our 
clients after the second hit instead of the first one. 

Do you have any considerations, suggestions about this?

Marco 


Marco Franceschetti
Head of Deliverability | ContactLab
marco.francesche...@contactlab.com
Via Natale Battaglia, 12 | Milano
contactlab.com/it 

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