All,
This is an odd scenario, but sadly one I find myself in.
Work is a large organisation, and currently does not have an SPF record.
The reason is that there are a large (and unknown) number of internal and
external parties that send mail on our domain, as well as sub-domains.
So, even if we
Dnia 10.01.2023 o godz. 22:40:56 Grant Taylor via mailop pisze:
>
> It doesn't help that part of me wants to integrate the SMTP client
> into the script instead of relying on the local MTA stack /
> infrastructure.
Why?
Your script will run as a part of existing mail flow anyway, within an
Hi, i've a little trouble with Iol/Wind server..
last week my mail queue increase with many iol reject:
(host smtp-in.libero.it[213.209.1.129] said: 451 too many messages, slow
down. [smtp-07.iol.local; LIB_650] (in reply to end of DATA command))
The problem is that the queue now has the old
Dňa 11. januára 2023 11:56:35 UTC používateľ Roberto Tagliaferri - Tosnet srl
via mailop napísal:
>In postfix i've lower the parameter default_destination_concurrency_limit
>fromthe default (5) to 5 but.. nothing.
Hmm, are you sure, that change from "default (5)" to 5 is lowering?
regards
Is there some kind of forwarding address or something that would end up
going through your mailgun account? The reason I ask is this header
right here:
Received: from reflectiv.net (os3-384-25366.vs.sakura.ne.jp
[133.167.109.120]) by db739d28cce8 with SMTP id ; Wed, 11 Jan
2023 00:26:59 GMT
Thank you everyone for your follow up.
Your suggestion, Jarland, is very interesting. I also find it odd to have
the sakura.ne.jp server appear out of nowhere!
If it were to be a hack of my account, it would be Mailgun->Gmail, that's
all. (well, I hope so)
... and, you put me on the right track!
Hi everyone!
Today, I received a spam ("I got full access to your computer and installed
a trojan" kind of email). In general, I completely ignore these, but today
was different:
The sender and recipient were my own email! What's odd is that I did
configure SPF (granted, with a "~") but also a
On Wed, Jan 11, 2023 at 10:00:50PM +0100, Cyril - ImprovMX via mailop wrote:
> Hi everyone!
>
> Today, I received a spam ("I got full access to your computer and installed
> a trojan" kind of email). In general, I completely ignore these, but today
> was different:
>
> The sender and recipient
Do you have an API ID and key/password for Mailgun somewhere that was
compromised? Was it saved somewhere like a password manager (think
Lastpass)? This looks as if the host submitted it directly to Mailgun,
hence it passed all email authentication.
On 1/11/2023 3:00 PM, Cyril - ImprovMX via
This looks like a message that maybe might've been sent to a reflectiv.net
address (perhaps the one advertised on your website? contact at
reflectiv.net?) and then automatically forwarded by Mailgun (which hosts
inbound mail for reflectiv.net) to a Google account (since Mailgun probably
doesn't do
Dňa 11. januára 2023 21:00:50 UTC používateľ Cyril - ImprovMX via mailop
napísal:
>Hi everyone!
>
>Today, I received a spam ("I got full access to your computer and installed
>a trojan" kind of email). In general, I completely ignore these, but today
>was different:
From time to time (once per
On 2023-01-11 at 16:29:51 UTC-0500 (Wed, 11 Jan 2023 22:29:51 +0100)
Peter N. M. Hansteen via mailop
is rumored to have said:
Generating a new, strong (long) password likely won't hurt, but it may
not
have been necessary. It is more likely that the miscreants injected
the
message somewhere
@Bill I was able to reproduce the original email I received without needing
my credentials. They weren't compromised.
Le mer. 11 janv. 2023, 23:20, Bill Cole via mailop a
écrit :
> On 2023-01-11 at 16:29:51 UTC-0500 (Wed, 11 Jan 2023 22:29:51 +0100)
> Peter N. M. Hansteen via mailop
> is
Looking at it again, I agree with Todd and Jarland's hypothesis;
Forwarding sounds more plausible than an API submission via compromised
credentials in this case. I think that hit the nail on the head. This
also correlates to one of Mailgun's product offerings
What makes you think you'd go over the limit if you haven't done the
discovery? You might be surprised that you may not exceed the lookup
count, as with optimization/analysis and proper SPF design (even without
flattening), the lookup count can be quite easily managed. This sounds
like a prime
Hi,
recently some users on my private server get masses of Bitcoin spam from
Gmail.
Subjects like "Get__your__transaction__0.7495__BTC" with attached PDFs,
which contain an image with a link on the first page, and then pages of
nonsense like "And what about the intruder? Arthur, you know
We actually have several rules that leverage non-disclosed recipient
emailing from gmail, and while there could be someone who simply puts
all the recipients in the bcc, and forgets to put in a to or cc, but if
you add another element to that, it is enough to hard block.
Example, that spammer
host reflectiv.net
reflectiv.net has address 75.2.60.5
reflectiv.net mail is handled by 10 mxb.mailgun.org.
reflectiv.net mail is handled by 10 mxa.mailgun.org.
Ummm
Now, it is pretty obvious that this is sent via MailGun, which of course
needs to improve it's outbound filters, seeing way
Typical gmail spam. They have been around for many years, google isn't able to
stop them.
If you look at their headers, you'll notice that almost all of them have the
same To: header as "undisclosed recipients" or pointing back to another gmail
address. These characteristics make them very
It appears that Cyril - ImprovMX via mailop said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Hi everyone!
>
>Today, I received a spam ("I got full access to your computer and installed
>a trojan" kind of email). In general, I completely ignore these, but today
>was different:
>
>The sender and recipient were
>
> What makes you think you'd go over the limit if you haven't done the
> discovery?
>
This would be because the ones that we are aware of, are the likes of
AmazonSES, Sendgrid, Mailchimp, Azure, OracleCloud, Mailjet, KANA/Verint,
just to name a few on top of our O365 instance and locally
> +1 to Mark's comments... Without discovery you'll never know if you're over
> the limits or not.
That's not the point though. It might be fine today. But at any time any one
of those providers could change a record you are including from them, and take
you over the limit, effectively a DoS
I’ll +1 to Jethro’s comments. NCSC will give you free DMARC reporting. We’ve
done as Strathclyde and pushed services out into subdomains. The top level
domain is just us and specific suppliers used for official comms. It wasn’t too
painful in the end but we spent a lot of time in report
Of those vendors you listed, Mailchimp doesn't send SPF aligned mail in
the RFC5321.mailfrom (return-path), and Sendgrid custom domain
authentication uses subdomain CNAMEs by default for the same, so you can
count those off your list of ones you need to worry about on your
organizational
+1 to Mark's comments... Without discovery you'll never know if you're over
the limits or not.
Setup a p=none policy, and see where the mail is coming from.
You may need to update systems, or change some domains to use subdomains,
or a different MailFrom: etc... but If massive global
Dnia 11.01.2023 o godz. 08:55:19 Matt Vernhout via mailop pisze:
>
> You may need to update systems, or change some domains to use subdomains,
> or a different MailFrom: etc... but If massive global corporations like
> Disney, HP, and Oracle, can figure it out you can too.
Those massive global
On 1/11/23 3:39 AM, Jaroslaw Rafa via mailop wrote:
Why?
Your script will run as a part of existing mail flow anyway, within
an existing MTA. Making use of this existing MTA seems to be the
logical choice, instead of trying to replicate its function yourself.
Consider a scenario where the
+1 to Laura's statement about Macros - and just wanted to add there is
also an open source solution that allows for self-hosted SPF macros on
github as well.
https://github.com/smck83/expurgate
On 1/11/2023 9:00 AM, Laura Atkins via mailop wrote:
On 11 Jan 2023, at 13:08, Simon Burke via
I've been doing something similar for a good long time.
Blogged about it here:
https://www.spamresource.com/2015/12/mail-forwarding-in-dmarc-world.html
The current version of my forwarding script rewrites the from address,
disables the authentication headers (re-authenticating the message
anew
> On 11 Jan 2023, at 13:08, Simon Burke via mailop wrote:
>
> All,
>
> This is an odd scenario, but sadly one I find myself in.
>
> Work is a large organisation, and currently does not have an SPF record. The
> reason is that there are a large (and unknown) number of internal and
>
On 1/11/23 3:39 AM, Jaroslaw Rafa via mailop wrote:
Why?
Another primary use case I have is a company owner moved a system from
the office to their house as they moved states and the new ISP filters
destination TCP port 25. So having something in the mail wrapper being
able to communicate
31 matches
Mail list logo
