[Top] [All Lists]

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

2019-12-12 22:33:26
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:> 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:>alioth-<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.

Attachment: pgpi9yb4An8O5.pgp
Description: PGP signature

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>