tead.
24.07.2019 18:27, Murray S. Kucherawy пишет:
> On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin
> <mailto:40corp.mail...@dmarc.ietf.org>> wrote:
>
> Nope, I mean 2 different things.
>
> 1. Why quarantine is useful (with pct=0).
>
> For exam
ected.
If you start with "p=quarantine" you have no feedback except reports,
and reports are received with a huge lag (up to 2 days) and do not
provide sufficient information to catch the exact problem and you can
not re-send the quarantined messages.
14.06.2019 18:42, Dotzero пишет:
>
&g
> How about, deleting policy Quarantine and instead rephrasing policy Reject:
>
> It is up to the receiving server if it rejects messages failing DMARC, or
> accepts and delivers them as Junk.
>
> (This does not change the protocol, just the wording)
>
> Regards
commendation to use MAIL FROM:<>/NOTIFY=NEVER are properly
> configured sites, that deal with improperly configured sites.
>
> Regards
> Дилян
>
> On June 4, 2019 2:48:32 PM GMT+03:00, Vladimir Dubrovin
> wrote:
>
> Reports are not sent to Return-Path address, empty
04.06.2019 15:08, Dave Crocker пишет:
> On 6/4/2019 1:48 PM, Vladimir Dubrovin wrote:
>> Reports are not sent to Return-Path address, empty return path does not
>> prevents report from being sent. Actually, report with empty
>
> My comment was meant about the DMARC report
> not contain a return address, in order to avoid looping. Shouldn't
> that apply to DMARC reports, too? If not, why?
>
> d/
>
--
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
st)
>
> _______
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
--
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
>> Over time you are unlikely to keep "legitimate" failures at 0%. There are
>> lots of moving parts and pieces that can cause a failure. It also depends on
>> the characteristics of the mail streams involved. The domain owner(s) and
>> staff will need to determine how much effort they are willing to put in
>> eliminating (legitimate) email failures. If I'm sending 10 million emails to
>> a domain and 1% are failing then I'm likely to look into it. On the other
>> hand, if I'm sending 100 emails a day to a domain from an overall large
>> system and 1% (1 email) is failing, that really falls into the noise and is
>> unlikely to get much time spent on it.
>>
>> Michael Hammer
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
--
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
viously has already the reported message and no
> intermediates are involved, that could expose
> additional information.
>
> Regards
> Дилян
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/list
gt;
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
--
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
18.05.2018 17:16, Steve Atkins пишет:
>> On May 18, 2018, at 7:09 AM, Vladimir Dubrovin wrote:
>>
>>
>> EFAIL exploitation requires MitM conditions. Neither DKIM nor DMARC protect
>> against attacker able to perform MitM.
>>
> It just requires the attacker to
> --Kurt
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
--
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
indicate the selector is legacy-only, e.g. o=sha512/eccp256 to
>>>> indicate
>>>> this selector should be ignored if verifier supports sha-512 and
>>>> eccp256.
>>>
>>> No. If the verifier is smart enou
bility, somehow you must indicate you are using it
for compatibility purposes only to prevent verifiers from acepting the
messages signed with weak key only if it's not accomplished by a
stronger signature.
07.04.2017 15:09, Scott Rose пишет:
> On 04/06/2017 05:28 PM, Vladimir Dubrovin wro
Without marking the published key as obsolete, downgrade attack is possible,
because attacker can still use a weaker key to spoof signature. пятница, 07
апреля 2017г., 02:58 +03:00 от John Levine jo...@taugh.com :
>>1. produce 2 different DKIM-Signatures with 2 different selectors:
>>slector1
s from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
--
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
nst spoofing attack, SPF only protects
SMTP envelope which is normally not visible to user. DMARC does.
P.S. Murray, may be it's better to add an option to DKIM-Signature or to
_dmarc DNS record to indicate some mechanism (DKIM or SPF) should not be
used for DMARC verification? It will work in abs
nybody can decrypt it with the public key.
>
> What am I missing?
>
There is no need to reverse if you know e-mail address. Alice can check
Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail
and check if he is in 'er&
ce al...@example.com
wants to check Bob bob@example is a recipients of Bcc, she can directly
get a hash of Bob's address with salt without the need to use any
rainbow tables. Asymmetric cryptography is requires with both sender's
and recipient's key to avoid this p
recipient_sig with
as_enc(recipient_privkey,
as_enc(sender_pubkey(recipient_sig))
remove random_salt to get hash(recipient_address)
for every recipient_address in envelope
compare calculated and decrypted hash(recipient_address), if
matches mark recipient_address
______
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
--
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
21 matches
Mail list logo
