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=santronics....@mail.ultrashed.buzz>
BODY=8BITMIME SUBMITTER=easysh...@ultrashed.buzz
S: 250
<27188-46690-410393-7123-hector.santos=santronics....@mail.ultrashed.buzz>...
Sender validation pending. Continue. (8BITMIME ok)
C: RCPT TO:<hector.san...@santronics.com>
** 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=santronics....@mail.ultrashed.buzz>
BODY=8BITMIME SUBMITTER=easysh...@ultrashed.buzz
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:i...@ultrashed.buzz;
ruf=mailto:i...@ultrashed.buzz;
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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
