Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Hector Santos <[e-mail]>]

This is real legit "feasible" proposal so let see where it goes ....

On 1/30/2021 5:41 AM, Alessandro Vesely wrote:>

>> Anyway, I'll let consensus fall where it may.

The solution is to consider the PRA/SUBMITTER protocols which was part 
of the SenderID protocol and many MTA clients already supported:

SUBMITTER https://tools.ietf.org/html/rfc4405
PRA https://tools.ietf.org/html/rfc4407

When the ESMTP Extension SUBMITTER is enabled, the client add can a 
SUBMITTER= parameter to the MAIL FROM. Example of a complete session 
this morning:

C: EHLO oscar.ultrashed.buzz
S: 250-mail.winserver.com, Pleased to meet you.
S: 250-SIZE 10240000
S: 250-8BITMIME
S: 250-SUBMITTER
S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
S: 250-AUTH=LOGIN
S: 250-HELP
S: 250 STARTTLS
C: MAIL 
FROM:<27188-46690-410393-7123-hector.santos=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]
S: 250 
<27188-46690-410393-7123-hector.santos=[e-mail]>... 
Sender validation pending. Continue. (8BITMIME ok)
C: RCPT TO:<[e-mail]>
** WCX Process: wcsap ret: 550 (63 msecs) (Rejected by WCSAP RBL Host 
bl.spamcop.net)
S: 550 Return Path not verifiable.
C: QUIT
S: 221 closing connection
** Completed. Elapsed Time: 530 msecs


Our wcSMTP supports the SUBMITTER SMTP Service Extension (RFC4405). 
The keyword SUBMITTER is advertised.  The client uses RFC4407 
Purported Responsible Address (PRA) to extra the PRA which is usually 
the 5322.From address and issues the MAIL FROM:

C: MAIL 
FROM:<27188-46690-410393-7123-hector.santos=[e-mail]> 
BODY=8BITMIME SUBMITTER=[e-mail]

So here we can see the 5322.From is different from the 5321.MailFrom 
return path, a subdomain but different.

My proposal is for the SMTP server to use this opportunity to do a 
DMARC look up for ultratrashed.buzz domain. Lets do this now:

v=DMARC1; p=none; fo=1; rua=mailto:[e-mail]; 
ruf=mailto:[e-mail];

And there is no DMARC record for the subdomain.

And note the EHLO subdomain, "oscar" vs "mail" for the return path.

But how does this help?


Well, the receiver now knows the there is a DMARC record and therefore:

1) The message MUST be signed but we won't know this until the payload 
is transferred,

2) SPF is expected. There is no SPF record any of three domains, and

3) The p=none means he doesn't really care if it alignment fails or 
they are not sure but its not reject|quarantine which means they don't 
expect alignment enforcement.

But considering there is DMARC record but no SPF record means there is 
a problem with this transaction. It can be refused probably on that 
basis. But as you can see, it was rejected but for RBL reasons. :-)

We SHOULD consider the two protocols (PRA/SUBMITTER) for DMARC/SPF 
integration. This extra bit of information help at SMTP before the 
potentially high overhead payload is transferred. That was the main 
MS-patented (frivolous) reason for this optimization -- to avoid the 
payload transfer overhead.

But the beauty of this proposal is that it is not new! There are 
clients out there that do support it and will extract the PRA and 
issue it at SMTP MAIL FROM state:

C: MAIL FROM:<return-path> [SUBMITTER=pra]

At the point, the SMTP client has some awareness of the payload and 
DMARC expectations.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos