Thanks for helps.
On Sat, Nov 23, 2019, at 11:07 AM, Richard Damon wrote:
> On 11/22/19 6:25 AM, Wesley Peng wrote:
> > Would this list break SPF then? Thanks
> >
> This list sends with an envelope sender in the lists domain, so it
> doesn't break general SPF, it will break DMARC SPF, since that
On 11/22/19 6:25 AM, Wesley Peng wrote:
> Would this list break SPF then? Thanks
>
This list sends with an envelope sender in the lists domain, so it
doesn't break general SPF, it will break DMARC SPF, since that check SPF
only to the From: domain.
This list doesn't modify messages in a way to
On 22.11.19 07:24, Richard Damon wrote:
Base SPF works through a traditional forwarder, because the base rules
for SPF allow the message to pass based on the domain of the Sender:
header, not just the From:. A proper forwarder will add a Sender: header
for itself, to indicate that while it was
On 22.11.19 06:15, Richard Damon wrote:
Normal forwarding will break SPF,
note that by "normal forwarding" Richard meant the old-school
"re-send mail to new recipient, keep its contents and the envelope sender"
where the keeping envelope sender is what breaks SPF. This is imho valid,
because
Dnia 22.11.2019 o godz. 13:16:41 Dominic Raferd pisze:
> Even so, the eu.org DMARC policy is 'none' so it is *not* advising receiver
> to quarantine or block emails that fail the DMARC policy (which begs the
> question of why bother with a DMARC policy at all of course).
Many domains have DMARC
On Fri, 22 Nov 2019 at 12:45, Jaroslaw Rafa wrote:
> Dnia 22.11.2019 o godz. 11:40:29 Dominic Raferd pisze:
> >
> > The limitations you describe affect SPF but not DMARC because DMARC can
> > rely *either* on SPF *or* on DKIM.
>
> But it probably depends on how the *recipient* configured DMARC
Dnia 22.11.2019 o godz. 07:24:03 Richard Damon pisze:
>
> Base SPF works through a traditional forwarder, because the base rules
> for SPF allow the message to pass based on the domain of the Sender:
> header, not just the From:. A proper forwarder will add a Sender: header
> for itself, to
Dnia 22.11.2019 o godz. 11:40:29 Dominic Raferd pisze:
>
> The limitations you describe affect SPF but not DMARC because DMARC can
> rely *either* on SPF *or* on DKIM.
But it probably depends on how the *recipient* configured DMARC checking and
the sender can't do anything about it - am I right?
On 11/22/19 6:25 AM, Jaroslaw Rafa wrote:
> Dnia 22.11.2019 o godz. 10:45:42 Wesley Peng pisze:
>> So mailing list makes DKIM or SPF failed?
>>
>> Thank you for your helps.
> My opinion is that the actual problem is that people who invented SPF and/or
> DMARC had wrong assumptions about how email
On Fri, 22 Nov 2019 at 11:26, Jaroslaw Rafa wrote:
> Dnia 22.11.2019 o godz. 10:45:42 Wesley Peng pisze:
> >
> > So mailing list makes DKIM or SPF failed?
> >
> > Thank you for your helps.
>
> My opinion is that the actual problem is that people who invented SPF
> and/or
> DMARC had wrong
No. It's how DMARC uses SPF.
Scott K
On November 22, 2019 11:25:47 AM UTC, Wesley Peng wrote:
>Would this list break SPF then? Thanks
>
>On Fri, Nov 22, 2019, at 7:15 PM, Richard Damon wrote:
>> On 11/21/19 11:47 PM, Wesley Peng wrote:
>> > Richard Damon wrote:
>> >> That is a question to ask
Would this list break SPF then? Thanks
On Fri, Nov 22, 2019, at 7:15 PM, Richard Damon wrote:
> On 11/21/19 11:47 PM, Wesley Peng wrote:
> > Richard Damon wrote:
> >> That is a question to ask them. Basically the strict DMARC policy is
> >> designed for transactional email, where spoofing is a
Dnia 22.11.2019 o godz. 10:45:42 Wesley Peng pisze:
>
> So mailing list makes DKIM or SPF failed?
>
> Thank you for your helps.
My opinion is that the actual problem is that people who invented SPF and/or
DMARC had wrong assumptions about how email works/should work.
They assumed email is a
On 11/21/19 11:47 PM, Wesley Peng wrote:
> Richard Damon wrote:
>> That is a question to ask them. Basically the strict DMARC policy is
>> designed for transactional email, where spoofing is a real danger. The
>> side effect of it is that addresses on such a domain really shouldn't be
>> used on
On Fri, 22 Nov 2019 at 09:56, Wesley Peng wrote:
> I meant I didn’t get it in my mail.ru inbox. The other providers may or
> may not reject it. Thanks.
>
> On Fri, Nov 22, 2019, at 5:52 PM, Wesley Peng wrote:
>
> Hi
>
> the mail I sent from mail.ru to this list got dropped, I didn’t get the
>
I meant I didn’t get it in my mail.ru inbox. The other providers may or may not
reject it. Thanks.
On Fri, Nov 22, 2019, at 5:52 PM, Wesley Peng wrote:
> Hi
>
> the mail I sent from mail.ru to this list got dropped, I didn’t get the
> message I sent.
>
>
> On Fri, Nov 22, 2019, at 4:41 PM,
Hi
the mail I sent from mail.ru to this list got dropped, I didn’t get the message
I sent.
On Fri, Nov 22, 2019, at 4:41 PM, Nick wrote:
> On 2019-11-22 04:21 GMT, Wesley Peng wrote:
> > The email I am using is with domain of mail.ru, which has the
> > strictest DMARC policy setting.
> >
> >
On Fri, 22 Nov 2019 at 08:42, Nick wrote:
> On 2019-11-22 04:21 GMT, Wesley Peng wrote:
> > The email I am using is with domain of mail.ru, which has the
> > strictest DMARC policy setting.
> >
> > So mailing list like postfix-users doesn't deliver my message to
> > myself on this domain. And
On 2019-11-22 04:21 GMT, Wesley Peng wrote:
> The email I am using is with domain of mail.ru, which has the
> strictest DMARC policy setting.
>
> So mailing list like postfix-users doesn't deliver my message to
> myself on this domain. And google groups rewrite the sender address
> to their own
> Am I right?
Yes Wesley you are right. So i don't like DMARC (with SPF).
Sincerely,
--
^고맙습니다 _地平天成_ 감사합니다_^))//
Richard Damon wrote:
The
side effect of it is that addresses on such a domain really shouldn't be
used on mailing lists,
Thanks for pointing out this. I never knew it.
Now I changed my mail to fastmail account, which I owned it for many
years. I just don't like its mobile app, it's just
Richard Damon wrote:
That is a question to ask them. Basically the strict DMARC policy is
designed for transactional email, where spoofing is a real danger. The
side effect of it is that addresses on such a domain really shouldn't be
used on mailing lists, or any other 3rd party senders not
On 11/21/19 11:21 PM, Wesley Peng wrote:
> Richard Damon wrote:
>> The typical options for the mailing list are
>>
>> 1) Just not allow people from such domains to post to the list (the
>> reject option you mention)
>>
>> 2) Rewrite the from address from people from such a domain to be from
>> the
Richard Damon wrote:
The typical options for the mailing list are
1) Just not allow people from such domains to post to the list (the
reject option you mention)
2) Rewrite the from address from people from such a domain to be from
the domain of the list (often the list address). This is
On 11/21/19 9:45 PM, Wesley Peng wrote:
> Greetings,
>
> When mail is relayed through mailing list, why the DMARC policy is
> possible to reject?
>
> For example, I sent mail from x...@mail.ru to y...@googlegroups.com
>
> Since mail.ru has the strictest DMARC policy, the recepients may
> choose to
Greetings,
When mail is relayed through mailing list, why the DMARC policy is
possible to reject?
For example, I sent mail from x...@mail.ru to y...@googlegroups.com
Since mail.ru has the strictest DMARC policy, the recepients may choose
to reject this mail which is relayed by googlegroups,
26 matches
Mail list logo
