Re: [dmarc-discuss] Inbound spoofed mails

[Edward Siewick via dmarc-discuss]

T Nguyen,
Please just describe your actual context. Folks can help you with the oddities.
Edward S.

On Jan 9, 2019, 12:49 PM, at 12:49 PM, Blason R  wrote:
>Hi Edward,
>
>How do I make it work for Inbound if my MTA/AntiSpam does not support?
>Not
>sure if I understood your question correctly but would appreciate if
>you
>can shed some light on this? lets say I am on google apps.
>
>Google Apps I guess bydefault takes care of Incoming mail. But what if
>I am
>using third party MTA which does not support Inbound DMARC checks? Yes
>most
>of them do support SPF and DKIM validation but not DMARC I guess.
>
>Please correct me if I am wrong.
>
>Thanks and regards,
>Blason R
>
>On Wed, Jan 9, 2019 at 7:00 PM Edward Siewick via dmarc-discuss <
>dmarc-discuss@dmarc.org> wrote:
>
>> Blason,
>>
>> Actually, consider implementing testing (SPF, DKIM) and DMARC for
>> inbound.  Since you've implemented for everybody else, why not put
>these to
>> use for your own organization?
>>
>> Edward S.
>>
>>
>> On 1/8/2019 10:26 PM, Blason R via dmarc-discuss wrote:
>>
>> Hi DMARC Team,
>>
>> What I understand is DMARC is very beneficial for the mails which are
>> being sent from my domain to third party. But can we stop the emails
>coming
>> at me pretending to be my own domain? My assumption again here is we
>can
>> not and need to have AntiSpam policy to block looking at SPF and
>DKIM?
>>
>> TIA
>> Thanks and Regards
>> Blason R
>>
>> ___
>> dmarc-discuss mailing
>listdmarc-discuss@dmarc.orghttp://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>
>> NOTE: Participating in this list means you agree to the DMARC Note
>Well terms (http://www.dmarc.org/note_well.html)
>>
>> ___
>> dmarc-discuss mailing list
>> dmarc-discuss@dmarc.org
>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>
>> NOTE: Participating in this list means you agree to the DMARC Note
>Well
>> terms (http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Inbound spoofed mails

[Blason R via dmarc-discuss]

Hi Edward,

How do I make it work for Inbound if my MTA/AntiSpam does not support? Not
sure if I understood your question correctly but would appreciate if you
can shed some light on this? lets say I am on google apps.

Google Apps I guess bydefault takes care of Incoming mail. But what if I am
using third party MTA which does not support Inbound DMARC checks? Yes most
of them do support SPF and DKIM validation but not DMARC I guess.

Please correct me if I am wrong.

Thanks and regards,
Blason R

On Wed, Jan 9, 2019 at 7:00 PM Edward Siewick via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Blason,
>
> Actually, consider implementing testing (SPF, DKIM) and DMARC for
> inbound.  Since you've implemented for everybody else, why not put these to
> use for your own organization?
>
> Edward S.
>
>
> On 1/8/2019 10:26 PM, Blason R via dmarc-discuss wrote:
>
> Hi DMARC Team,
>
> What I understand is DMARC is very beneficial for the mails which are
> being sent from my domain to third party. But can we stop the emails coming
> at me pretending to be my own domain? My assumption again here is we can
> not and need to have AntiSpam policy to block looking at SPF and DKIM?
>
> TIA
> Thanks and Regards
> Blason R
>
> ___
> dmarc-discuss mailing 
> listdmarc-discuss@dmarc.orghttp://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well terms 
> (http://www.dmarc.org/note_well.html)
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] help!

[Zachary Aab via dmarc-discuss]

The MAIL FROM is not easily spoofed if there is SPF, that's SPF's role.
The displayed Header From *is* easily spoofed, which is why we have DMARC.
DMARC is based on the displayed Header From that the user sees and matches
that domain to either the DKIM or the MAIL FROM, because if the Header From
is the same as a 'proven' domain (DKIM is proven by DKIM passing and MAIL
FROM is proven by SPF passing), then the displayed Header From is also
proven.
If the displayed Header From is not the same as a proven domain (DKIM or
MAIL FROM), then the DMARC policy (p=__) is consulted to see if the owner
of the domain wants the email quarantined or rejected.
My best,
Zack Aab

*Zack Aab | Sr. Deliverability Strategist*

*Inbox Pros  *1995 N Park Place | Suite 300 | Atlanta
O: 678.214.3739 | C: 706-870-1061 | z...@inboxpros.com


On Wed, Jan 9, 2019 at 11:54 AM T Nguyen  wrote:

> Thank you Zack for the prompt response.
>
> The mfrom, MAIL FROM (aka Return-Path aka Envelope-From), is very easily
> spoofed and we received lots of spoofing email where Envelope-From is not
> aligned with the display "from", where recipients sees the sender email
> address. From my understanding that dmarc alignment is based on domain of
> this display "from", correct?
> --
> *From:* Zachary Aab 
> *Sent:* Wednesday, January 9, 2019 11:30 AM
> *To:* Paul Rock
> *Cc:* T Nguyen; dmarc-discuss@dmarc.org
> *Subject:* Re: [dmarc-discuss] help!
>
> That is a mistake a LOT of senders make, and it's often the fault of their
> ESP which provided incomplete or even wrong information.
> Just to reinforce what Paul said:
> The Header From IS NOT checked for SPF.  The MAIL FROM (aka Return-Path
> aka Envelope-From) IS checked for SPF.
> My best,
> Zack Aab
>
> 
> *Zack Aab | Sr. Deliverability Strategist*
> 
> *Inbox Pros
> 
> *1995 N Park Place | Suite 300 | Atlanta
> O: 678.214.3739 | C: 706-870-1061 | z...@inboxpros.com
>
>
> On Wed, Jan 9, 2019 at 11:09 AM Paul Rock  wrote:
>
> SPF checks run against the actual mfrom domain (or in some cases the
> HELO/EHLO domain), in this case it'll check the SPF record for ESP.com,
> which passed. SPF doesn't know/care about the from header (and in many
> systems, that header hasn't even crossed the wire yet) so it can't do an
> SPF check using the from header. That's why DMARC looks at both the
> alignment of the SPF domain in question as well as the SPF result. And just
> to be clear, the DMARC logic is only looking at the result of a SPF check,
> it doesn't try to do one on it's own. Because ESP.com doesn't align with
> abc.com
> ,
> it fails the SPF portion of the DMARC evaluation.
>
> On Wed, Jan 9, 2019 at 11:01 AM T Nguyen  wrote:
>
> Yes Zack, I meant aSPF relaxed as it's implied without specifically
> indicated in dmarc record.
>
> To clarify ESP.com(111.222.333.444 - source IP) is the external web app
> Email Service Provider so abc.com
> 
> (MX & DMARC enable) users can send email to large internet groups via
> non-MX subdomain u...@xyz.abc.com. ( this subdomain xyz.abc.com
> 
> has spf record with include sender ESP.com - note that abc.com
> 
> only receives rua for the subdomain but no spf record for ESP.com).
>
> The second part of 

Re: [dmarc-discuss] help!

[Zachary Aab via dmarc-discuss]

That is a mistake a LOT of senders make, and it's often the fault of their
ESP which provided incomplete or even wrong information.
Just to reinforce what Paul said:
The Header From IS NOT checked for SPF.  The MAIL FROM (aka Return-Path aka
Envelope-From) IS checked for SPF.
My best,
Zack Aab

*Zack Aab | Sr. Deliverability Strategist*

*Inbox Pros  *1995 N Park Place | Suite 300 | Atlanta
O: 678.214.3739 | C: 706-870-1061 | z...@inboxpros.com


On Wed, Jan 9, 2019 at 11:09 AM Paul Rock  wrote:

> SPF checks run against the actual mfrom domain (or in some cases the
> HELO/EHLO domain), in this case it'll check the SPF record for ESP.com,
> which passed. SPF doesn't know/care about the from header (and in many
> systems, that header hasn't even crossed the wire yet) so it can't do an
> SPF check using the from header. That's why DMARC looks at both the
> alignment of the SPF domain in question as well as the SPF result. And just
> to be clear, the DMARC logic is only looking at the result of a SPF check,
> it doesn't try to do one on it's own. Because ESP.com doesn't align with
> abc.com, it fails the SPF portion of the DMARC evaluation.
>
> On Wed, Jan 9, 2019 at 11:01 AM T Nguyen  wrote:
>
>> Yes Zack, I meant aSPF relaxed as it's implied without specifically
>> indicated in dmarc record.
>>
>> To clarify ESP.com(111.222.333.444 - source IP) is the external web app
>> Email Service Provider so abc.com (MX & DMARC enable) users can send
>> email to large internet groups via non-MX subdomain u...@xyz.abc.com. (
>> this subdomain xyz.abc.com has spf record with include sender ESP.com -
>> note that abc.com only receives rua for the subdomain but no spf record
>> for ESP.com).
>>
>> The second part of the record is very confusing. If the mfrom performs
>> spf check against abc.com then it should fail.  spf only passes if
>> checking against the subdomain xyz.abc.com
>>
>> *​*
>> *abc.com ​*
>> *​*
>> *​*
>> * ​*
>> * ​*
>> *ESP.com​*
>> *mfrom​*
>> *pass​*
>> *​*
>> **
>>
>> --
>> *From:* Zachary Aab 
>> *Sent:* Wednesday, January 9, 2019 10:25 AM
>> *To:* T Nguyen
>> *Cc:* Paul Rock; dmarc-discuss@dmarc.org
>> *Subject:* Re: [dmarc-discuss] help!
>>
>> >does DMARC fail even with adfs and adkim implicitly as “r” relaxed?
>>
>> By adfs do you mean aspf?  If so: yes, "r" aka "relaxed" means that
>> subdomains of the same parent domain are considered aligned (eg:
>> sub.abc.com
>> 
>> is aligned with othersub.abc.com
>> )
>> and "s" aka "strict" means that the subdomains must be identical in order
>> to align.  Either way, the authentication (DKIM or SPF) still must share a
>> parent domain with the Header From.  The example shows two different parent
>> domains: "esp.com
>> "
>> in the MAIL FROM and "abc.com
>> "
>> in the Header From, so they are not aligned and cannot pass DMARC without
>> changing.
>>
>> My best,
>> Zack Aab
>>
>> 
>> *Zack Aab | Sr. Deliverability Strategist*
>> 
>> *Inbox Pros
>> 
>> *1995 N Park Place | Suite 300 | Atlanta
>> O: 678.214.3739 | C: 706-870-1061 | 

Re: [dmarc-discuss] Inbound spoofed mails

[Edward Siewick via dmarc-discuss]

Blason,

Actually, consider implementing testing (SPF, DKIM) and DMARC for 
inbound.  Since you've implemented for everybody else, why not put these 
to use for your own organization?


Edward S.


On 1/8/2019 10:26 PM, Blason R via dmarc-discuss wrote:

Hi DMARC Team,

What I understand is DMARC is very beneficial for the mails which are 
being sent from my domain to third party. But can we stop the emails 
coming at me pretending to be my own domain? My assumption again here 
is we can not and need to have AntiSpam policy to block looking at SPF 
and DKIM?


TIA
Thanks and Regards
Blason R

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)