Hi Michael
Just a short update on DigitalOcean after I to
their abuse desk that it took them almost a month to take down an
ubs.com phishing site and they didn't even seem to bother to look at
the other spam sources I mentioned in the same incident report.
It again took them about two weeks to r
On Fri, 2019-04-26 at 15:01 +0100, Gary Hussey wrote:
> e was a victim of a spam session where approximately 200k spam emails was
> trying to leave our server over the bank holiday weekend. On tuesday this
> was discovered and around 50k had left our server. This was resolved but
> we are still exp
We're currently seeing quite a bunch of messages from
no-re...@sendgrid.net which contain broken Content-Type headers like
> Content-Type: multipart/report; report-type=delivery-status;
> Date: Mon, 29 Apr 2019 10:09:15 UTC
> boundary="2821519d3987dfb8"
> Content-Transfer-Encoding: binary
bounda
Bill,
On 28/04/2019 20:37, Bill Cole via mailop wrote:
> On 28 Apr 2019, at 13:05, Grant Taylor via mailop wrote:
>
>> On 4/27/19 11:43 PM, Bill Cole wrote:
>>> I can't say "should" because that's a site-specific/sender-specific
>>> choice.
>>
>> As is the choice to (over)sign headers, even non-e
Hi List
I wonder if DigitalOcean is running for some social media related
wake-up call.
I Twittered to @digitalocean about the lack of responsiveness from their
abuse desk.
They promptly replied via Twitter:
"We apologise for the trouble. Our security & operation team is already
looking into it
On Sat, 2019-04-27 at 15:09 -0400, Bill Cole wrote:
> Yes, because the signature included the Sender and List-* headers,
> probably non-existent originally, which mailing lists typically
> (including this one) add to messages they relay.
>
Like most mailing lists, mailop both modifies the Subj
If you follow any of the white hat groups, or security researchers, you
will see a lot of them already doing it with little or no effect..
(Which means of course people stop bothering to report it)
However, a little birdie told me that certain government agencies are
finally waking up and gath
On Mon, 29 Apr 2019 07:26:23 -0700, Michael Peddemors via mailop
wrote:
>PS, pgHammer went quiet yesterday.. either someone caught/killed his C&C
>server, or the actor realized that there was too much attention on the
>activity. That doesn't mean those servers listed should not still be
>take
> I Twittered to @digitalocean about the lack of responsiveness from their
> abuse desk.
>
> They promptly replied via Twitter:
>
> "We apologise for the trouble. Our security & operation team is already
> looking into it."
>
> As I still had a case open with them, I appended your nice list of
>
On 2019-04-29 7:58 a.m., Michael Rathbun via mailop wrote:
On Mon, 29 Apr 2019 07:26:23 -0700, Michael Peddemors via mailop
wrote:
PS, pgHammer went quiet yesterday.. either someone caught/killed his C&C
server, or the actor realized that there was too much attention on the
activity. That doe
On Sun, Apr 28, 2019 at 11:33:07AM -0600, Brielle Bruns via mailop wrote:
> A slack channel would be cool regardless [...]
No, it wouldn't. You might find it instructive to read their S-1 filing,
referenced here:
Slack Warns Investors It's a Target for Nation-State Hacking
https
On 2019-04-29 8:18 a.m., Anne P. Mitchell, Esq. via mailop wrote:
I wonder if we should*all* tweet to them, including the hashtag
#DigitalOceanHostsBadGuys ?;-)
When Anne suggests something like this.. ;)
Done!
--
"Catch the Magic of Linux..."
--
On 2019-04-29 8:37 a.m., Michael Peddemors via mailop wrote:
On 2019-04-29 8:18 a.m., Anne P. Mitchell, Esq. via mailop wrote:
I wonder if we should*all* tweet to them, including the hashtag
#DigitalOceanHostsBadGuys ?;-)
When Anne suggests something like this.. ;)
Done!
Speaking of.. an
On 4/29/2019 9:30 AM, Rich Kulawiec via mailop wrote:
On Sun, Apr 28, 2019 at 11:33:07AM -0600, Brielle Bruns via mailop wrote:
A slack channel would be cool regardless [...]
No, it wouldn't. You might find it instructive to read their S-1 filing,
referenced here:
Slack Warns Investo
On Mon, 29 Apr 2019, Jim Popovitch via mailop wrote:
On April 29, 2019 3:46:03 AM UTC, John Levine via mailop
wrote:
Still waiting to hear when mailop.org adds its SPF record.
Didn't it take almost 2 years the last time we waited on mailop.org to fix a
cert?😊
The current web cert for the
On 4/28/19 11:50 PM, Kurt Andersen (b) via mailop wrote:
Mailop either needs to implement ARC (there are solutions for that which
work with Mailman 2 & 3), sign outgoing mail with its own DKIM signatures
(along with header munging), or implement SPF authentication in order
to have authenticatio
Am 28.04.2019 um 20:24 schrieb Grant Taylor via mailop:
> I think the list MTA should accept the messages with DKIM oversigned
> headers, remove said DKIM-Signature headers, pass the DKIM-less message
> into the mailing list for normal processing.
What I see from my Google DMARC reports is
DKIM/
Wow, what a thread.
So, to be clear, we don't treat DKIM failure any different than if the
message lacks DKIM, at least in general (its always possible there are
manual rules that do things differently that were targeted at specific
campaigns, and I'm not sure if the ML thinks differently, but thi
On 4/29/2019 12:51 PM, Andrew C Aitchison via mailop wrote:
I'm trying to alert the exim developers to the suggestions that people
have made in this thread; but it would be easier to ask them to
subscribe to
mailop if the archive didn't have an expired certificate.
I joined the exim-dev lis
On 29 Apr 2019, at 15:55, Brandon Long via mailop wrote:
Wow, what a thread.
So, to be clear, we don't treat DKIM failure any different than if the
message lacks DKIM, at least in general
Great!
[...]
I'm surprised that no one has fixed mailman's bounce handling to be
smarter,
It is, if i
In article <231a8e51-7a1d-10ea-e777-f157156e7...@akxnet.de> you write:
>The list server has no control over other's SPF records, so the SPF
>check will fail if the FROM of the original message is retained and an
>SPF record exists for that domain.
Mailing lists put their own address as the bounce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2019-04-29 at 09:12 -0700, Michael Peddemors via mailop wrote:
> Speaking of.. anyone have any insight into these guys?
> They keep popping up on various CDN's eg, DO, AZURE, etc..
> 45.32.138.192 (M) 1 mta-wk-3.mk3.ipruz.
On 4/29/2019 12:12 PM, Michael Peddemors via mailop wrote:
On 2019-04-29 8:37 a.m., Michael Peddemors via mailop wrote:
Speaking of.. anyone have any insight into these guys?
They keep popping up on various CDN's eg, DO, AZURE, etc..
Most, possibly all of these networks are blocked here. It
Thanks everyone for suggestions about stopping them, but we already have
that.. but to be clearer, just wanted to see if anyone had any insight
into the "operator" behind them..
Any sense of legitimacy at all?
Who's lists are they washing?
PS, don't block them, just tell them every email exis
On 30/04/2019 05:35, Andreas Klein via mailop wrote:
> so the SPF
> check will fail if the FROM of the original message is retained and an
> SPF record exists for that domain.
ancient FUD
I was a very, *very* early adopter of SPF, I always hear these claims,
but my mails always get through SPF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2019-04-29 at 16:49 -0700, Michael Peddemors via mailop wrote:
> PPS, You know the IP(s) can change at any time ;)
That is what cron is for. So far, synapp.io has been very good about
listing *only* their own address validators in their spf
26 matches
Mail list logo
