stalwartlabs/mail-auth

DMARC verify queries against root TLD

williamdes opened this issue · 7 comments

williamdes commented

Using

user@domain.corp

The code will query _dmarc.corp -> I verified with Wireshark

Refs:

The code should probably query dmarc.domain.corp instead.
There is a few special TLDs on the links I mentioned

Some validation code (used in Laravel) explicitly has such a list hard coded: https://github.com/egulias/EmailValidator/blob/877577656387a3ffabae60dd4c425059179834cb/src/Validation/DNSCheckValidation.php#L23-L40

image

mdecimus commented

How are you testing this? I modified the tests inverify.rs to use domain.corp and the right domain is queried:

            // Strict - Pass
            (
                "_dmarc.domain.corp.",
                concat!(
                    "v=DMARC1; p=reject; sp=quarantine; np=None; aspf=s; adkim=s; fo=1;",
                    "rua=mailto:dmarc-feedback@domain.corp"
                ),
                "From: hello@domain.corp\r\n\r\n",
                "domain.corp",
                "domain.corp",
                DkimResult::Pass,
                SpfResult::Pass,
                DmarcResult::Pass,
                DmarcResult::Pass,
                Policy::Reject,
            ),
williamdes commented

Hey,

This is still on my TODO list

Do you mind keeping it open ?
Did you find anything else ?

mdecimus commented

I can't reproduce this issue. In addition to that the library is being actively used in Stalwart SMTP to validate DMARC. If you have a way to reproduce the problem please reopen.

williamdes commented

I still can confirm this:

1700433718:INFO:hickory_server::server::server_future:969:request:7847 src:UDP://10.222.222.2#60169 QUERY:_25._tcp.emails.mail-server.intranet.:TLSA:IN qflags:RD,AD response:NXDomain rr:0/1/1 rflags:RD,AA
1700433718:DEBUG:hickory_server::server::server_future:90:received udp request from: 10.222.222.2:58216
1700433718:DEBUG:hickory_server::server::server_future:1021:request:28866 src:UDP://10.222.222.2#58216 type:QUERY dnssec:false QUERY:_dmarc.corp.:TXT:IN qflags:RD
1700433718:DEBUG:hickory_server::authority::catalog:488:performing name: _dmarc.corp. type: TXT class: IN on .

Will dig more into this

williamdes commented

More digging leads me to this

php-sut-1  | debug level 4; message: Sending with mail()
php-sut-1  | debug level 4; message: Sendmail path: /usr/sbin/sendmail -t -i
php-sut-1  | debug level 4; message: Envelope sender: sesame@aladin.private
php-sut-1  | debug level 4; message: To: contact@desportes.corp
php-sut-1  | debug level 4; message: Subject: Mail to myself, postgreydelay
php-sut-1  | debug level 4; message: Headers: Date: Sun, 19 Nov 2023 23:45:20 +0000
php-sut-1  | From: sesame@aladin.private
php-sut-1  | Message-ID: <hBWfE6gghesiCicWeo7z3kKA4QBAXoDBqXRuvhp68@testing.mail-server.intranet>
php-sut-1  | X-Mailer: PHPMailer 6.8.1 (https://github.com/PHPMailer/PHPMailer)
php-sut-1  | MIME-Version: 1.0
php-sut-1  | Content-Type: text/plain; charset=iso-8859-1
php-sut-1  | 
php-sut-1  | 
php-sut-1  | debug level 4; message: Additional params: -fsesame@aladin.private
php-sut-1  | debug level 4; message: Result: true

I need to dig a bit further

But there is probably a denial of service attack somewhere into this, it causes the server to do a delivery loop of some kind and print this when it stops

2023-11-19T23:46:13.158837Z  INFO delivery{id=4325785819845 return_path="root@desportes.corp" nrcpt=1 size=48581}:attempt{domain="desportes.corp" attempt_number=0}: smtp::outbound::session: context="message" event="rejected" mx="emails.mail-server.intranet" reason=Code: 450, Enhanced code: 4.4.6, Message: Too many Received headers. Possible loop detected.
2023-11-19T23:46:13.159425Z  INFO delivery{id=4325785819845 return_path="root@desportes.corp" nrcpt=1 size=48581}: smtp::outbound::delivery: Delivery was not possible, message re-queued for delivery. context="queue" event="requeue" reason="delivery-incomplete"
mdecimus commented

I still can confirm this:

1700433718:DEBUG:hickory_server::server::server_future:1021:request:28866 src:UDP://10.222.222.2#58216 type:QUERY dnssec:false QUERY:_dmarc.corp.:TXT:IN qflags:RD
1700433718:DEBUG:hickory_server::authority::catalog:488:performing name: _dmarc.corp. type: TXT class: IN on .

What you are seeing here is most likely a DMARC DNS tree walk.

But there is probably a denial of service attack somewhere into this, it causes the server to do a delivery loop of some kind and print this when it stops

This problem is unrelated to DMARC.

williamdes commented

What you are seeing here is most likely a DMARC DNS tree walk.

Probably but on this list of special TLDs it should not walk them