[Top] [All Lists]

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

2019-12-13 08:55:16

I don't see any way around this. I see no other ways to handle this.

I'm not sure how viable this method is. I think the client should look for
MAIL FROM command response and then retry with a non VERP address when the
local-part exceed 64 characters.

501 Syntax error in parameters or arguments
455  Server unable to accommodate parameters
555  MAIL FROM/RCPT TO parameters not recognized or not implemented

I don't see any way around this. I see no other ways to handle this.

On Fri, Dec 13, 2019 at 10:03 AM Sam Varshavchik 

Viruthagiri Thirumavalavan writes:

Most servers don't enforce that 64 character limit in the local-part.
some minority servers certainly do. What happens when those minority
enforces that limit and the end user has the "firstname.lastname@domain"

I expect users of those servers to have occasional problems subscribing
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
them to a @<URL:> address. This is how the
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
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
The sender can proactively refuse to send mail when it constructs a
address with a local part that exceeds 64 characters. It would be a shame
it did that, only to discover later that the non-VERP receiver can
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:>alioth-<URL:mailto:courier-

So when intermediaries get involved, local-part limitation gonna cause
at least for few cases.  I think you need to address that part in your

Sure. My old draft already has a "Security" section that waxed eloquently
lesser topics. I just completed a first pass on converting the last
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
thing, and then try the online converter, and if all looks good I'll dump
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
long. So, according to this, all mass mail that Godaddy forwards from
Youtube and Linked-In already exceeds 64 characters in local-part. Looks
me like that ship has already sailed.

Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.
ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>