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
<mrsam(_at_)courier-mta(_dot_)com>
wrote:
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.
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp