> On May 22, 2017, at 10:01 PM, Hal Murray wrote:
>
>> ARC is the very-near-future solution to much of this. Get your vendors on it.
>> http://arc-spec.org
>
> I'm missing something. What keeps a bad guy from setting up shop and
> claiming to be forwarding mail and
> ARC is the very-near-future solution to much of this. Get your vendors on it.
> http://arc-spec.org
I'm missing something. What keeps a bad guy from setting up shop and
claiming to be forwarding mail and claiming that SPF was valid on the crap he
is sending?
It seems to me that a critical
On Mon, May 22, 2017, at 18:59, frnk...@iname.com wrote:
> Just starting last week we started seeing our outbound queues fill up
> with undeliverable client messages generated because of this one-click
> unsubscribe feature. Since this Apple feature has been in place for
> over six months, I’m
Just starting last week we started seeing our outbound queues fill up with
undeliverable client messages generated because of this one-click unsubscribe
feature. Since this Apple feature has been in place for over six months, I’m
surprised we haven’t seen this until now.
Here are the
Well, the obvious usage of ARC where DKIM is not a solution is for any
modifying hop, such as a mailing list. The mailing list can DKIM sign the
modified message, but it then lacks alignment and also takes on "ownership"
of the message (see discussion about forwarding in general taking the
DKIM is solution.
ARC is not solution and never will. Actually, I see no any reason for
ARC, really. If you trust sender, you can trust his Received: without
any cryptography. If you do not trust sender, you can not trust ARC
regardless of cryptography. ARC doesn't work without trusts. The only
On 5/22/2017 3:46 PM, valdis.kletni...@vt.edu wrote:
On Mon, 22 May 2017 14:42:20 -0700, W Kern said:
I am talking about the scenario where a third party sender WITH an -all
SPF record sends to my customer and then MY customer forwards it
elsewhere (gmail, hotmail).
So you accept spam if it
Forwarding is complicated, but it's not going away.
If you take "ownership" of forwarded mail by changing the MAIL FROM, then
you are more likely to be charged for the spam you forward. If you don't
take ownership, then spf will fail, and a good spam filter will be more
likely to notice it's
On Mon, 22 May 2017 14:42:20 -0700, W Kern said:
> I am talking about the scenario where a third party sender WITH an -all
> SPF record sends to my customer and then MY customer forwards it
> elsewhere (gmail, hotmail).
So you accept spam if it has a valid SPF?
pgp1vLecxuz_9.pgp
Description:
On Mon, May 22, 2017 at 6:05 PM, Michael Wise via mailop
wrote:
>
> At least a Mailing List is in a position to rewrite the headers so that SPF
> works when it sends the traffic out.
>
Yep, but only those managed by ppl who know how to keep things
updated, patched, etc.
At least a Mailing List is in a position to rewrite the headers so that SPF
works when it sends the traffic out.
Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting
On 5/22/2017 2:54 PM, Steve Atkins wrote:
ARC is the very-near-future solution to much of this. Get your vendors on it.
http://arc-spec.org
Very interesting. Will research more on it.
Thanks.
-bill
___
mailop mailing list
mailop@mailop.org
> On May 22, 2017, at 2:42 PM, W Kern wrote:
>
>
> We quarantine inbound SPF failures. Customers complain but we point that out.
> So those are not the issue.
>
> I am talking about the scenario where a third party sender WITH an -all SPF
> record sends to my customer
> On May 22, 2017, at 12:57 PM, Michael Wise via mailop
> wrote:
>
>
> Forwarding ... is GROSSLY insecure and causes far more problems than it
> solves.
> Just grabbing the traffic from the original INBOX with IMAP or POP3 is a much
> more secure solution.
/me gestures
On 5/22/2017 1:31 PM, valdis.kletni...@vt.edu wrote:
On Mon, 22 May 2017 13:21:08 -0700, W Kern said:
Then it's your fault for *accepting* the spam/virus that ended up getting
forwarded.
We quarantine inbound SPF failures. Customers complain but we point that
out. So those are not the
On Mon, 22 May 2017 13:21:08 -0700, W Kern said:
> On 5/22/2017 11:22 AM, valdis.kletni...@vt.edu wrote:
> > not an SPF problem.
> > Forwarding has worked just fine for 30 or so years, if not longer. The
> > "problem" only happens if you insist on attaching SPF to it.
> Except when it is a
On 5/22/2017 11:22 AM, valdis.kletni...@vt.edu wrote:
not an SPF problem.
Forwarding has worked just fine for 30 or so years, if not longer. The
"problem" only happens if you insist on attaching SPF to it.
Except when it is a shared server and that server forwards enough
spam/virii
Forwarding ... is GROSSLY insecure and causes far more problems than it solves.
Just grabbing the traffic from the original INBOX with IMAP or POP3 is a much
more secure solution.
Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
On Mon, 22 May 2017 10:59:21 -0700, Michael Peddemors said:
> Some have pointed out on the list the problem with 'forwarding', however
> that is a forwarding problem, and not an SPF problem.
Forwarding has worked just fine for 30 or so years, if not longer. The
"problem" only happens if you
On 17-05-20 12:24 PM, Steve Atkins wrote:
On May 19, 2017, at 6:58 PM, Bryan Blackwell wrote:
Hi folks,
Please pardon the noob question, just want to make sure this is what a proper
SPF record should look like:
example.org.IN TXT "v=spf1 mx ~all"
It's
20 matches
Mail list logo