I count 41 characters already, in that local address, right there.
"firstname.lastname@domain" is a fairly popular format of corporate
E-mail
addresses. And if some of us had to use this E-mail address convention,
it's
a fair bet that GNU mailman's bounce addresses will exceed the 64 char
limit
on the local part. But I'll be surprised if it ever causes any problems,
anywhere; and I never heard of this ever happening.
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?
For the record, plenty of folks in this mailing list use corporate e-mail
addresses. I have a lengthy name. If I go for "firstname.lastname@domain"
format, then the bounce address may exceed the 64 character limit. Since
your proposal deal with SMTP extension, you can explicitly mention not to
enforce the 64 character local-part limitation when the server support your
extension.
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 @gmail.com address. This is how the Return-Path looks
like in my Gmail account when I send an email from giri(_at_)dombox(_dot_)org
to the
forwarding address.
<SRS0=JUYF=2A=dombox.org=giri(_at_)bounce(_dot_)secureserver(_dot_)net>
Since Godaddy acts as an intermediary here, they need to rewrite the MAIL
FROM address.
If Godaddy use the same giri(_at_)dombox(_dot_)org in the MAIL FROM
(1) SPF is gonna fail. So the mail may end up in spam.
(2) There's gonna be bounce issues due to SPF failure. Gmail have
to silently drop the mail in order to prevent backscatter spam.
To use your address as an example.
Original: <mrsam(_at_)courier-mta(_dot_)com>
Debian:
<nut-upsuser-bounces+mrsam=courier-mta(_dot_)com(_at_)alioth-lists(_dot_)debian(_dot_)net>
Godaddy: <SRS0=2wQu=2C=alioth-lists.debian.net=nut-upsuser-bounces+mrsam=
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.
Thanks
On Thu, Dec 12, 2019 at 5:39 PM Sam Varshavchik
<mrsam(_at_)courier-mta(_dot_)com>
wrote:
Viruthagiri Thirumavalavan writes:
If implementations start to adopt your VERP extension, that's a good
thing
especially for large mail services since it's saves plenty of bandwidth.
So
feel free to use the content from my draft in your proposal.
Thanks, I'll take a look at it, shortly.
I have no recollection that the 64 char limit on local E-mail addresses
was
ever mentioned as an issue in front of me. Mine is not the only mailing
list
software that uses the same approach of encoding mailing list bounces
addresses. Looking through my mailbox, one of my mailing lists' return
addresses:
<nut-upsuser-bounces+mrsam=courier-mta(_dot_)com(_at_)alioth-lists(_dot_)debian(_dot_)net>
According to that one's headers, this is GNU mailman. Which is much more
widespread than anything that I wrote. Furthermore, my VERP extension did
not pioneer this encoding. It's already been in use, back in 1999; I
merely
parroted it. It's been in use for at least 20 years. I do not remember
reading any reports that it caused any issues, anywhere.
I count 41 characters already, in that local address, right there.
"firstname.lastname@domain" is a fairly popular format of corporate
E-mail
addresses. And if some of us had to use this E-mail address convention,
it's
a fair bet that GNU mailman's bounce addresses will exceed the 64 char
limit
on the local part. But I'll be surprised if it ever causes any problems,
anywhere; and I never heard of this ever happening.
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp