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

Viruthagiri Thirumavalavan writes:

> Most servers don't enforce that 64 character limit in the local-part. But  
> some minority servers certainly do. What happens when those minority servers  
> enforces that limit and the end user has the "firstname.lastname@domain" type  
> address? 
I expect users of those servers to have occasional problems subscribing to  
mailing lists that use GNU mailman, and other software that already uses  
VERP return addresses.
> However, the real problem starts when multiple hops involved.  For example I  
> have a forwarding address in Godaddy which catches all the mails and forwards  
> them to a @<URL:http://gmail.com>gmail.com address. This is how the Return- 
> Path looks like in my Gmail account when I send an email from  
> <URL:mailto:giri(_at_)dombox(_dot_)org>giri(_at_)dombox(_dot_)org to the forwarding address.
Well, I break down this situation in several smaller pieces.

An SMTP sender that implements VERP implicitly acknowledges that it accepts  
E-mail addresses with longer local parts.
An SMTP server that advertises a VERP SMTP extension acknowledges the same.

So now you have a VERP SMTP sender connecting to a non-VERP SMTP server.

Mail that does not have a VERP - nothing changes to that.

Mail with a VERP return address - that's the only combination where there  
may be an issue, but that's only a possibility, and by no means a certainty.  
The sender can proactively refuse to send mail when it constructs a return  
address with a local part that exceeds 64 characters. It would be a shame if  
it did that, only to discover later that the non-VERP receiver can receive  
mail with longer local-parts.
The sender can roll the dice and attempt to send the mail anyway. Chances  
are pretty good that it will be fine. The possibility of a rejection are  
quite small.
I don't see any way around this. I see no other ways to handle this.

> Godaddy: <SRS0=2wQu=2C=<URL:http://alioth-lists.debian.net>alioth- 
> lists.debian.net=nut-upsuser-bounces+mrsam=<URL:mailto:courier- 
> mta(_dot_)com(_at_)bounce(_dot_)secureserver(_dot_)net>courier-mta(_dot_)com(_at_)bounce(_dot_)secureserver(_dot_)net>
>
> 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.
But, back to the above: I looked at what's in my mailbox. I see mass mail  
from Youtube and Linked in, with local parts that are 55 and 59 characters  
long. So, according to this, all mass mail that Godaddy forwards from  
Youtube and Linked-In already exceeds 64 characters in local-part. Looks to  
me like that ship has already sailed.

pgpi9yb4An8O5.pgp
Description: PGP signature

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