>Any good ideas how to prevent that problem?
A) don't use SRS
B) don't blindly forward mail without spam filtering it first
C) really, don't use SRS
R's,
John
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listi
>If I understand what's going on, Y! is doing an OR on DKIM & SPF and in
>this case, your SPF record is bypassed by the DKIM pass.
No, Y! only uses DKIM to decide where to send FBL reports. This is a
feature.
As Steve said, the way to solve the problem is not to sign mail
written by random stra
Seth Charles via mailop wrote:
Hello,
We're running into a strange issue I'm wondering if anyone on this
list has seen before.
We have a client that is running into blocks at Gmail, and the reason
given is, "550 5.7.1 [167.89.88.20] The IP address sending this
message does not have a PTR rec
The only benefit I can see from sending the exact same message from
somewhere else would be to drive recipients to the same payload link, which
suggests another possible way to stop this from paying off after detection:
Make it so that all content links get turned into redirects you control,
and ca
What Steve said: Unique domains per account, or for different groups. We
had to do this for link-tracking domains: userid.example.com instead of
links.example.com for all accounts.
-Tim
On Fri, Aug 12, 2016 at 10:34 AM, Steve Atkins wrote:
>
> > On Aug 11, 2016, at 5:42 PM, Robert Mueller wrot
On 8/12/16 03:28, Robert Mueller wrote:
It's also easy for the spammer to test. Signup trial account, send to
gmail. No DKIM signature or wrong domain? Use a credit card to pay.
Still not working? Buy a stolen account on some black market. Still not
working due to message content? just tweak th
> On Aug 12, 2016, at 1:53 PM, Seth Charles via mailop
> wrote:
>
> Hello,
> We're running into a strange issue I'm wondering if anyone on this list has
> seen before.
>
> We have a client that is running into blocks at Gmail, and the reason given
> is, "550 5.7.1 [167.89.88.20] The IP addr
This PTR record fails the reverse check:
>host 167.89.88.20
20.88.89.167.in-addr.arpa domain name pointer
o1.webmaillist.flowerdeliveryexpress.com.
>host o1.webmaillist.flowerdeliveryexpress.com
Seth Charles via mailop пишет:
> Hello,
> We're running into a strange issue I'm wondering if an
Hello,
We're running into a strange issue I'm wondering if anyone on this list has
seen before.
We have a client that is running into blocks at Gmail, and the reason given
is, "550 5.7.1 [167.89.88.20] The IP address sending this message does not
have a PTR record setup. As a policy, Gmail does no
> On Aug 12, 2016, at 11:52 AM, Vick Khera wrote:
>
> On Fri, Aug 12, 2016 at 12:34 PM, Steve Atkins wrote:
>> You're vouching for / accepting responsibility for every mail you sign.
>> If your users are bad actors - as they are in this case - you're accepting
>> responsibility for that.
>
> S
We are trying to set up a new FBL with Microsoft via the JMRP but are
unable to add IPs to the feed. The feed basically is created w/o IPs and
new IPs cannot be added. Anyone else seeing the same issue?
Torsten
*Torsten Reinert*
Manager of Global Email Deliverabili
On Fri, Aug 12, 2016 at 12:34 PM, Steve Atkins wrote:
> You're vouching for / accepting responsibility for every mail you sign.
> If your users are bad actors - as they are in this case - you're accepting
> responsibility for that.
So if I took any random message that I came upon signed by you an
On Fri, 12 Aug 2016, Benoit Panizzon wrote:
>Our Email Services implement SRS to forward emails from SPF protected
>domains.
>Unfortunately [...] spam and exam...@eblcom.ch has choosen to have
>spam emails tagged in the subject and delivered.
Mainly you shouldn't use SRS, but if you keep using i
> On Aug 11, 2016, at 5:42 PM, Robert Mueller wrote:
>
> Hi mailop
>
> So it appears at the moment that we're experiencing a DKIM replay attack
> against us. Basically some people are signing up a trial FastMail
> account, sending a couple of emails to a gmail account (to get them DKIM
> signed
Robert Mueller пишет:
>
>> 1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in
>> time.
>
> Assuming the receiving side looks at it. But you probably mean the x=
> tag anyway to set the expiry time, the RFC explicitly says though:
>
> INFORMATIVE NOTE: The "x=" tag is not intended
> Laura Atkins has some pretty cool ideas here:
> https://wordtothewise.com/2014/05/dkim-injected-headers/
> I'd be interested to see if including those headers twice in the
> signature works, so an altered or second instance of them would
> fail DKIM.
They didn't alter any of the headers or add
> 1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in
> time.
Assuming the receiving side looks at it. But you probably mean the x=
tag anyway to set the expiry time, the RFC explicitly says though:
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-
Laura Atkins has some pretty cool ideas here:
https://wordtothewise.com/2014/05/dkim-injected-headers/
I'd be interested to see if including those headers twice in the signature
works, so an altered or second instance of them would fail DKIM.
And have you had success including the t= and/or an agg
There are few ways to mitigate attacks:
1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in time.
2. Use per-user selectors with different keys (as it was advised) and
remove DKIM records if replay attack is detected
or simply switch to new selector if per-user keys are impossib
Hello
Our Email Services implement SRS to forward emails from SPF protected
domains.
So the envelope server is being rewritten to the domain of the
'forwarder'.
Example:
eloig...@whutherl.local-girls.org => exam...@eblcom.ch (forwards to
exam...@gmail.com)
After SRS Rewriting the sender looks
On 12/08/2016 01:42, Robert Mueller wrote:
2. I bet a number of services out there are using the domains in DKIM
signed emails for reputation tracking. So this may be affecting the
reputation of our domains, even though we're not the genuine source of
the majority of the emails.
Hmm, looking at
21 matches
Mail list logo
