+1 on moving the discussion elsewhere
Tim
On Mon, Apr 8, 2019 at 10:27 PM Murray S. Kucherawy
wrote:
>
>
> On Mon, Apr 8, 2019 at 5:27 PM Douglas E. Foster <
> fost...@bayviewphysicians.com> wrote:
>
>> Scott, you misunderstand what this type of standard would look like. It
>> would defines
On Mon, Apr 8, 2019 at 5:27 PM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:
> Scott, you misunderstand what this type of standard would look like. It
> would defines Use Cases that the device should address, with some
> acknowledgement to the tradeoffs between perceived risk and p
No, I think you seriously misunderstand what the IETF does. It doesn't do
product specifications, it does interoperability specifications.
This is seriously off-topic for the DMARC working group list anyway.
Scott K
P.S. There are open source components to accomplish all the requirements you
l
Scott, you misunderstand what this type of standard would look like. It
would defines Use Cases that the device should address, with some
acknowledgement to the tradeoffs between perceived risk and perceived
difficulty of implementation.
Implementation suggestions may be part of the use
Let's pursue the use cases for this information. Existing DMARC feedback
has three uses, after interpretation:
Compromised accounts: "Account appears to be comprised and
sending spam. Please shut it down." Configuration errors: "We may have
blocked legitimate mail, indicating th
In article
you write:
>This neglects the benefit to the domain operators of receiving the reports
>about abuse of their domain space. For the end recipient of the bogus
>traffic, there is no difference.
I agree that the reports are useful, regardless of the policy.
I just wish we could figure o
On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)" wrote:
>On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster <
>fost...@bayviewphysicians.com> wrote:
>
>> I don't know how to express my shock at today's conversations. One
>of
>> the shocks comes from this:
>>
>> We have consensus that the b
On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:
> I don't know how to express my shock at today's conversations. One of
> the shocks comes from this:
>
> We have consensus that the better email filters do not need the DMARC for
> PSDs standard, because th
What part of that do you need an explanation for? It seems pretty clear to
me. If you disagree with the statement then you should explain the
rationale for your disagreement.
Michael Hammer
On Mon, Apr 8, 2019 at 6:55 PM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:
> I don't know ho
I don't know how to express my shock at today's conversations. One of the
shocks comes from this:
We have consensus that the better email filters do not need the DMARC for
PSDs standard, because they are already blocking non-existent domains.
The inferior email filters are not expected t
On Mon, 2019-04-08 at 09:50 -0400, Douglas E. Foster wrote:
[...snip...]
> My focus is on defining a framework for discussing product capabilities,
> while leaving room for vendors to add value above the minimum
> configuration.
That sounds more like what organisations such as Gartner are there fo
RBLs are alive and well.
I understand the risk of helping the bad guys, but I think the evidence is
that silence is hurting the good guys more than the bad guys.
My focus is on defining a framework for discussing product capabilities,
while leaving room for vendors to add value above the
Since bad email filters are the problem, why is there no IETF working
group to define the expected behavior of email filters?More
importantly, can we start one NOW?
It's kind of outside the IETF's expertise -- there are people in the IETF
(not in this WG) who believe that DNSBLs were a fail
Your question confirms my core argument: We do not have consensus around
email filter requirements because IETF has focused on sender behavior
rather than recipient behavior.
To the specifics:
By "secure email relay", I am referring to Zixmail-type functioinality.
It is complex c
On 08/04/2019 12:02, Douglas E. Foster wrote:
> I had only these rudimentary requirements:
> [...] A secure-email method for outbound messages with sensitive
> content
Rudimentary? How secure; what's your threat model?
Those two things often don't go together.
(I should declare an int
Have the national CIRT groups made an issue about needing to block
non-existent domains?
Because a spammer can create a non-existent government agency like
"irs.audit.gov", this email weakness becomes a national security issue and
should be handled as a CVE.This should get the vendors mo
Mr Levine brings up the valid point that there are a lot of mail filters
with inadequate capabilities. I determined that my two products have
inexcusable weaknesses, so I went shopping.
I had only these rudimentary requirements:
IP filteringReverse DNS filtering Multi-factor w
17 matches
Mail list logo
