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

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.
> Sam,
>
> 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 https://github.com/svarshavchik/verp-smtpext

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-encodedrlocal=rdomain@sdomain
>
> where
>
> 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.

pgpgrx_Vtluay.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp