On 12/12/2019 11:33 PM, Sam Varshavchik wrote:
So when intermediaries get involved, local-part limitation gonna
cause issues at least for few cases. I think you need to
address that part in your draft.
Sure. My old draft already has a "Security" section that waxed
eloquently on lesser topics. I just completed a first pass on
converting the last version of my draft to XML, without any further
changes. xsltproc balked on rfc2629.xslt's version=2.0, but seemed to
work if I manully change it to 1.0, the end results look reasonable,
but I want to look through the whole thing, and then try the online
converter, and if all looks good I'll dump it on github and start a
discussion about concrete changes.
I am interested in reviewing the XML file. I give it a quick look over
the weekend. I need to catch up with XMK2RFC myself.
Regarding section 7, currently the Verp-01 draft section 7 describes
the very simple algorithm to generate the verp-encoded address:
slocal is the left hand side of the return path,
sdomain is the right hand side of the return path,
rlocal is the left hand side of the recipient path,
rdomain is the right hand side of the recipient path,
encodedrlocal is the VERP-01 specific character encoding of rlocal.
The encodedrlocal encodes the characters: @, :, %, !, and +
I noted in the updated nroff source version, you updated it to include
dashes and squared brackets. This is good. Many slocal and rlocal
values will include the dash so it was needed to help with parsing the
parts by the MDA Verp Bounce Processor.
Do you have any examples of rlocal where squared brackets needed to be
Also, are you aware of any other VERP variations? I am particularly
interested in adding an optional hashed or another encoded version,
but also in detecting them. I did a grep of all the "C: MAIL FROM"
for the past three day, and there appears to be a wide range of
VERP-like encoding formats. I can see the VERP-01 formats as well,
but I see many with hashes, guids, etc.
ietf-smtp mailing list