On Sun 11/Feb/2024 01:47:12 +0100 Scott Kitterman wrote:
On Saturday, February 10, 2024 7:39:37 PM EST Murray S. Kucherawy wrote:
On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton wrote:
This actually concerns me a bit. If having multiple From: addresses causes
a message to be out of scope for
I have been thinking about the other way that an attacker could have two
>From addresses: by having two From headers.Not a problem as long as
the evaluator rejects the message based on standards violation.
But what if the evaluator does not test for dual headers because the
configuration is
Murray S. Kucherawy skrev den 2024-02-11 01:39:
-MSK, participating
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
avoid this on maillists please
why is stupid mua using quoted-printable while its html ?, i dont blame
anyone from make silly msg
On Saturday, February 10, 2024 7:39:37 PM EST Murray S. Kucherawy wrote:
> On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton wrote:
> > > No, it's perfectly fine to declare that DMARC only applies to certain
> > > classes of messages.
> >
> > This actually concerns me a bit. If having multiple From:
On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton wrote:
> > No, it's perfectly fine to declare that DMARC only applies to certain
> > classes of messages.
>
> This actually concerns me a bit. If having multiple From: addresses causes
> a message to be out of scope for DMARC and therefore bypass a
On 5 Feb 2024, at 22:22, Murray S. Kucherawy wrote:
> No, it's perfectly fine to declare that DMARC only applies to certain
> classes of messages.
This actually concerns me a bit. If having multiple From: addresses causes a
message to be out of scope for DMARC and therefore bypass a p=reject
On Tue 06/Feb/2024 07:22:49 +0100 Murray S. Kucherawy wrote:
On Mon, Feb 5, 2024 at 10:22 AM Alessandro Vesely wrote:
On 05/02/2024 00:29, Murray S. Kucherawy wrote:
On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote:
RFC 7489 says this:
In order to be processed by DMARC, a
On Mon, Feb 5, 2024 at 10:56 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The evidence from Google is that multi-valued From DOES have usage and is
> usually malicious. That should be sufficient evidence to conclude l that
> the security hole must be plugged, not ignored.
>
On Mon, Feb 5, 2024 at 10:22 AM Alessandro Vesely wrote:
> On 05/02/2024 00:29, Murray S. Kucherawy wrote:
> > On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote:
> >
> >>> What do we think has changed since then that warrants reconsidering
> that
> >>> position? Have we started to see
The volume of current attacks should not be a consideration, and
speculation about future risks is vacuous. The industry routinely raises
C.V.Es against newly discovered and not-yet-exploited security holes, and
we should act the same way.
The evidence from Google is that multi-valued From DOES
On 05/02/2024 00:29, Murray S. Kucherawy wrote:
On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote:
What do we think has changed since then that warrants reconsidering that
position? Have we started to see multi-value From attacks?
A DMARC filter has to do something when it sees a
It appears that Murray S. Kucherawy said:
>-=-=-=-=-=-
>
>On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote:
>
>> > What do we think has changed since then that warrants reconsidering that
>> > position? Have we started to see multi-value From attacks?
>>
>> A DMARC filter has to do
On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote:
> > What do we think has changed since then that warrants reconsidering that
> > position? Have we started to see multi-value From attacks?
>
> A DMARC filter has to do something when it sees a multi-value From:.
Why? It hasn't so far
I see no conflict.
A domain with DMARC enforcement asserts that it sends only authenticated
messages. Since multiple-From messages cannot be fully authenticated,
such messages are inconsistent with the domain owner's stated practices
Therefore, the domain owner's published Failure disposition
On Sat 03/Feb/2024 21:44:42 +0100 Murray S. Kucherawy wrote:
On Sun, Jan 28, 2024 at 5:40 AM Alessandro Vesely wrote:
I think this point about alignment of Sender is definitely correct,
Let's also recall there was a proposal to consider Sender: anyway.
And also let's recall that the
Checking each domain poses some restrictions on adding more authors on the
From: line. As you say, even if a message is being written four hands, current
MSA standards only allow one author to authenticate. Depending on outgoing
filters capabilities, the message will likely get a dmarc=pass
Even in the unlikely event that all From addresses can be authenticated
with DKIM, the result still cannot be trusted. It would be easy for an
attacker to anticipate signatures that will be added in transit, and use
those signatures to create false authentication.
RFC 7489 treats a
On Sun, Jan 28, 2024 at 5:40 AM Alessandro Vesely wrote:
> > I think this point about alignment of Sender is definitely correct,
>
> Let's also recall there was a proposal to consider Sender: anyway.
>
And also let's recall that the community has previously rejected the idea
of involving Sender
On Sun 28/Jan/2024 14:39:55 +0100 I wrote:
[...]
To handle appropriately means receivers are on their own w.r.t DMARC.) It
is a hole: >
From: presid...@whitehouse.gov , user@attackdomain
[...]
For Sender:, instead, we need to also require that the aligned domain be the
one of the _first_
Ale is right, the document needs to address the problem.
I agree with Google that multiple-From has no important use-case, and
therefore a wise evaluator should simply reject the message. For the same
reason, I believe the RFC5322.bis group should have deprecated the
feature.But since that
On Sat 27/Jan/2024 16:13:08 +0100 Scott Kitterman wrote:
On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote:
Ignoring, as Section 11.5 points out, exposes an attack vector that must be
taken into consideration. That section says:
[C]are must be taken by the receiving
On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote:
> On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote:
> >> On Jan 19, 2024, at 10:19 AM, Todd Herr
> >> wrote:
> >>
> >> Perhaps the way forward for DMARC is to look for a Sender header when
> >> there is more than one
Assume this RFC5322 header:
From: user@attackdomain, presid...@whitehouse.gov
For messages like this:
- Verifying one identity (e.g. "user@attackdomain") does nothing to say
that the unverified identity is used with authorization.
- Technical issues mean that it will be rare,
On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote:
On Jan 19, 2024, at 10:19 AM, Todd Herr
wrote:
Perhaps the way forward for DMARC is to look for a Sender header when there is more than one RFC5322.From domain and use that for DMARC processing, with the stipulation that messages that
> On Jan 19, 2024, at 10:19 AM, Todd Herr
> wrote:
>
>
> Perhaps the way forward for DMARC is to look for a Sender header when there
> is more than one RFC5322.From domain and use that for DMARC processing, with
> the stipulation that messages that don't contain such a Sender header are
>
On Fri, Jan 19, 2024 at 10:55 AM Dotzero wrote:
> The problem with relying on the Sender header is that unless a Sender
> header matches the right hand side (domain) of the email address in the
> From field, you can't tell if there is a legitimate relationship between
> Sender and From.
>
> I
On Fri, Jan 19, 2024 at 10:20 AM Todd Herr wrote:
> On Thu, Jan 18, 2024 at 9:28 PM Hector Santos 40isdg@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>> As a long time implementer and integrator of IETF protocols, my mail
>> engineering view ….
>>
>> The thing is RFC 822, 2822 and 5322 allows for a
On Thu, Jan 18, 2024 at 9:28 PM Hector Santos wrote:
> Hi,
>
> As a long time implementer and integrator of IETF protocols, my mail
> engineering view ….
>
> The thing is RFC 822, 2822 and 5322 allows for a single 5322.From header
> to have multiple addresses:
>
> from = "From:" mailbox-list
Hi,
As a long time implementer and integrator of IETF protocols, my mail
engineering view ….
The thing is RFC 822, 2822 and 5322 allows for a single 5322.From header to
have multiple addresses:
from = "From:" mailbox-list CRLF
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
So it is
I have a data point.
When we (Google) did an experiment/analysis of this a couple of years ago
the conclusion was
a) multi-value From are relatively rare and mostly look like abuse or
mistakes rather than intentional.
b) Users generally don't care about those messages if they end up in spam.
On 1/17/24 2:56 AM, Alessandro Vesely wrote:
[ Discussion of what to do with multi-valued From: in messages ]
However, since DMARC bears the blame of banning multi-valued From:, it
is appropriate for it to say something about the consequences and
possible workarounds.
DMARC doesn't ban
On 1/11/24 10:46 AM, Murray S. Kucherawy wrote:
What I recall from when we wrote that was that the first paragraph
really means "Most MTAs reject this anyway so it shouldn't even get to
your DMARC filter" and the second means "If it does get to you, here's
how you should probably react."
As with the mailing list problem, when the recipient expects authentication
but the sender cannot provide it, the sender is disadvantaged.
Nor an I concerned about the limitations of a particular MSA product.
However, we know that mailing list posts almost always start as authorized
messages, so
On Wed, Jan 17, 2024 at 2:56 AM Alessandro Vesely wrote:
> Since email format allows multi-valued From:, its meaning is
> straightforward.
>
Syntax, yes, but meaning? That seems debatable. Does the order of values
matter, for example?
As John says, it can also be the result of some kind of
On Tue 16/Jan/2024 19:24:29 +0100 Murray S. Kucherawy wrote:
On Tue, Jan 16, 2024 at 2:03 AM Alessandro Vesely wrote:
On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:
It appears that Scott Kitterman said:
I don't think that's sensible at all. It's not the place of a signing
filter to
On Tue, Jan 16, 2024 at 10:24 AM Murray S. Kucherawy
wrote:
> As I recall, with milter in particular, the MTA will add a missing Date
> field, which the filter never actually sees and thus cannot sign. The
> filter only sees the message exactly as it was presented to the MTA. As a
> result, if
On Tue, Jan 16, 2024 at 2:03 AM Alessandro Vesely wrote:
> On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:
> > It appears that Scott Kitterman said:
> >>I don't think that's sensible at all. It's not the place of a signing
> filter to modify the message.
>
> A signing filter, as part of
The purpose of DMARC is to demonstrate that the purported author (From) is
either the actual author or the authorized agent of the actual author.
Because of practical difficulties, this is an indirect process: DMARC
PASS demonstrates that a specific sending domain is authorized to speak on
On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:
It appears that Scott Kitterman said:
I don't think that's sensible at all. It's not the place of a signing filter
to modify the message.
A signing filter, as part of an MSA _has to_ modify the message in order to
enhance the
It appears that Scott Kitterman said:
>I don't think that's sensible at all. It's not the place of a signing filter
>to modify the message. I think it would be reasonable to either add a
>signature for
>each from domain or to decline to sign it at all, but since DKIM doesn't care
>about
On January 15, 2024 4:49:10 PM UTC, Alessandro Vesely wrote:
>On 11/01/2024 18:15, Todd Herr wrote:
>> On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote:
>>
>>> https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1
>>>
>>> "The case of a syntactically valid multi-valued
On 11/01/2024 18:15, Todd Herr wrote:
On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote:
https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1
"The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge. The process in this case is to
apply
Thank to both of you.
@Murray: Re-reading the sentences with your input, that would make sense
@Todd: Indeed, DMARCbis is pretty clear about it.
I look forward for DMARCbis to be published, as that will lead to one less
edge-case to worry about.
Regards,
Damien
On Jan 11, 2024, at 13:46,
In addition to what Todd offered:
On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote:
> The RFC first states:
>
> "Messages bearing a single RFC5322.From field containing multiple
> addresses (and, thus, multiple domain names to be evaluated) are
> typically rejected because the sorts of
On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote:
> Hello,
>
> A question I have reading the RFC7489 and more precisely the part «6.6.1
> Extract Author Domain».
> https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1
>
>
> The RFC first states:
>
> "Messages bearing a single
Hello,
A question I have reading the RFC7489 and more precisely the part «6.6.1
Extract Author Domain».
https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1
The RFC first states:
"Messages bearing a single RFC5322.From field containing multiple
addresses (and, thus, multiple domain
46 matches
Mail list logo
