On Thu, 22 Aug 2019 09:39:31 +0100, Laura Atkins via mailop
wrote:
>Not sure I understand this point of view. I think everyone should be rejecting
>after DATA, if only to stop the abuse of the email address validation
>services.
For defined spam traps here, we accept the message (although we
For any high volume email handlers, there’s very little information available
at the Edge when it comes to EndOfData.
And rejecting after that is catastrophic more often than not.
And yes, it outs your trap to those who bother to look at their logs.
Which might only be the occasional email
The mitigation form may help you.
I have seen IPs not shown as blocked by SNDS panel have 550's for days and
go away after escalated ticket for the support team.
Regards.
Em qui, 22 de ago de 2019 às 12:21, Benoit Panizzon via mailop <
mailop@mailop.org> escreveu:
> Hi List
>
> One of our mail
> On Thu, Aug 22, 2019 at 6:50 AM Ralf Hildebrandt via mailop
> wrote:
>>
>> * Mathieu Bourdin :
>> > Hi again,
>> >
>> >
>>
>> > First, a precision: my reply is missing 2 lines wich, for short,
>> > were saying: "but usually you don't get listed on the first sending to
>> > a trap,
>>
>> Yes,
On Thu, Aug 22, 2019 at 6:50 AM Ralf Hildebrandt via mailop
wrote:
>
> * Mathieu Bourdin :
> > Hi again,
> >
> >
>
> > First, a precision: my reply is missing 2 lines wich, for short,
> > were saying: "but usually you don't get listed on the first sending to
> > a trap,
>
> Yes, because that
+1
But now if we can ONLY get Amazon, GoogleCloud, and Azure to start doing
the same thing ;) Still far too many bad actors relying on the network
being 'too big to block' and very loose SWIP/rwhois.
On 2019-08-22 8:41 a.m., Laura Atkins via mailop wrote:
In my experience, when the bounce
On 22/08/2019 16:08, Benoit Panizzon via mailop wrote:
One of our mail platform IP has once more been hit by an outlook.com
blocking:
host outlook-com.olc.protection.outlook.com[104.47.4.33] said: 550 5.7.1
Unfortunately, messages from [157.161.12.116] weren't sent. Please contact
your Internet
In my experience, when the bounce message says "Please contact your Internet
service provider since part of their network is on our block list (S3150).”
That means that Microsoft is seeing problems across a wide range of IPs in a
space and they don’t have a clear picture of where the customer
Hi List
One of our mail platform IP has once more been hit by an outlook.com
blocking:
host outlook-com.olc.protection.outlook.com[104.47.4.33] said: 550 5.7.1
Unfortunately, messages from [157.161.12.116] weren't sent. Please contact
your Internet service provider since part of their network is
* Mathieu Bourdin :
> Hi again,
>
>
> First, a precision: my reply is missing 2 lines wich, for short,
> were saying: "but usually you don't get listed on the first sending to
> a trap,
Yes, because that would instantaneously blacklist all servers sending
double-opt-in
mails
> it's more an
On 8/22/2019 3:40 AM, Michael Hallager via mailop wrote:
How they do this - and I kidd you not - if they offer "data entry"
jobs to people in cheaper labour countries (the Philippines for
example) to manually get past CAPCHAS.
That is what many think is happening - and maybe that is
Hi again,
First, a precision: my reply is missing 2 lines wich, for short, were saying:
"but usually you don't get listed on the first sending to a trap, it's more an
accumulation of emails to different traps that get you in trouble form what I
understand of how traps work".
That's why when
* Mathieu Bourdin :
> >*** Shouldn't spam traps reject all mails after the END-OF-DATA? ***
>
> If they did, they would be easily identifiable, and thus would have no value.
Well, the sender wouldn't know if it's a trap or if the server is just
FUBARed in some odd way.
> The thing with
> On 22 Aug 2019, at 08:53, Mathieu Bourdin via mailop
> wrote:
>
>> *** Shouldn't spam traps reject all mails after the END-OF-DATA? ***
>
> If they did, they would be easily identifiable, and thus would have no value.
Not sure I understand this point of view. I think everyone should be
>*** Shouldn't spam traps reject all mails after the END-OF-DATA? ***
If they did, they would be easily identifiable, and thus would have no value.
The thing with spamtraps is that they should not be in your DB in the first
place (especially pristine ones) or should have been trimmed from your
* Michael Wise via mailop :
>
>
> Sometimes ... pristine ... isn't.
Thought so.
> Presuppose y'all are doing bounce processing?
Yes.
This raises a question regaring spam traps:
*** Shouldn't spam traps reject all mails after the END-OF-DATA? ***
1) That way the spam trap addresses would
On 2019-08-22 19:30, Alberto Miscia via mailop wrote:
Same here and, as a word of warning, they find a way to get through
some of our anti-bot / anti-listbombing systems and we are working on
it. I guess we have to expect a new "flood" in the coming months..
How they do this - and I kidd you
>
> We've been able to spot a bunch of our clients getting their (unprotected)
> forms abused since a few months. Bad guys seem to be at work, or maybe just
> preparing something for after the summer holidays.
Same here and, as a word of warning, they find a way to get through some of
our
Hi Team
Just a follow up on that case, as from the feedback I got it looks
others are also affected by this problem.
I finally managed to get the attention of an Amazon SES Tech who agreed
to look into the issue and got an explanation of what most probably
happened.
Amazon SES does NOT block
19 matches
Mail list logo
