[Top] [All Lists]

Re: [ietf-smtp] Proposal: Updating VERP Specification

2019-12-13 18:16:51
Hector Santos writes:

On 12/12/2019 11:33 PM, Sam Varshavchik wrote:

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.

I put it up now, at

The online tool currently chokes on the bibxml library's RFC 1425 reference, it doesn't like one of its stub author entries. I removed it and manually pulled the reference in, rather than reference it from the bibxml library.

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 encoded?

Not rlocal but rdomain.

An E-mail address can still be local@[aaa.bbb.ccc.ddd], pedantically.

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.

The VERP-01 formats you're seeing most likely preceded my draft. This kind of bounce processing was already fairly common <1999.

To this day Courier still treats it as a private extension, and advertises XVERP instead of VERP, in EHLO. I am not aware of any other actual implementation. There may be one, but I haven't heard of it.

Attachment: pgpgrx_Vtluay.pgp
Description: PGP signature

ietf-smtp mailing list