Semi-OT: recipient delimiter spec/std?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Semi-OT: recipient delimiter spec/std?

Patrick Ben Koetter
Everybody seems to use recipient delimiters. I wonder if there's a standard
that specifies a recipient delimiter functionality or did it just appear one
day and people adopted it without a spec or anything.

Anybody knows?

p@rick


--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Wietse Venema
Patrick Ben Koetter:
> Everybody seems to use recipient delimiters. I wonder if there's a standard
> that specifies a recipient delimiter functionality or did it just appear one
> day and people adopted it without a spec or anything.
>
> Anybody knows?

As far as I know, the basic email RFCs have no concept of structured
local parts.  All they require is that the local part of an address
satisfies the syntax rules. If you know that you will never have
a username with an 'x' in it, you could use 'x' as the field
separator.

However, there are some developments for "subaddress" support, e.g.
http://tools.ietf.org/html/draft-newman-email-subaddr-00.

        Wietse

> p@rick
>
>
> --
> All technical questions asked privately will be automatically answered on the
> list and archived for public access unless privacy is explicitely required and
> justified.
>
> saslfinger (debugging SMTP AUTH):
> <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Erick Calder
On Sep 25, 2009, at 6:34 AM, Wietse Venema wrote:

> Patrick Ben Koetter:
>> Everybody seems to use recipient delimiters. I wonder if there's a  
>> standard
>> that specifies a recipient delimiter functionality or did it just  
>> appear one
>> day and people adopted it without a spec or anything.
>>
>> Anybody knows?
>
> As far as I know, the basic email RFCs have no concept of structured
> local parts.  All they require is that the local part of an address
> satisfies the syntax rules. If you know that you will never have
> a username with an 'x' in it, you could use 'x' as the field
> separator.
>
> However, there are some developments for "subaddress" support, e.g.
> http://tools.ietf.org/html/draft-newman-email-subaddr-00.

this brings to mind: I've long used plussed addresses and love that  
feature but my only complaint is that many systems disallow the + sign  
in an e-mail address... is there a way to have a character bag work as  
the delimiter? i.e. any of a list of characters? (obviously a dot "."  
could also serve well as a delimiter since it's well accepted... but  
not as nice as + or /, or even -)

- e

p.s there's another good reason for me: my address is [hidden email] which  
is too short for many sites... so I usually then use e
+[hidden email] which allows me to know, when I get spam at that  
address, where my address was stolen from.
Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Wietse Venema
Erick Calder:

> On Sep 25, 2009, at 6:34 AM, Wietse Venema wrote:
>
> > Patrick Ben Koetter:
> >> Everybody seems to use recipient delimiters. I wonder if there's a  
> >> standard
> >> that specifies a recipient delimiter functionality or did it just  
> >> appear one
> >> day and people adopted it without a spec or anything.
> >>
> >> Anybody knows?
> >
> > As far as I know, the basic email RFCs have no concept of structured
> > local parts.  All they require is that the local part of an address
> > satisfies the syntax rules. If you know that you will never have
> > a username with an 'x' in it, you could use 'x' as the field
> > separator.
> >
> > However, there are some developments for "subaddress" support, e.g.
> > http://tools.ietf.org/html/draft-newman-email-subaddr-00.
>
> this brings to mind: I've long used plussed addresses and love that  
> feature but my only complaint is that many systems disallow the + sign  
> in an e-mail address... is there a way to have a character bag work as  
> the delimiter? i.e. any of a list of characters? (obviously a dot "."  
> could also serve well as a delimiter since it's well accepted... but  
> not as nice as + or /, or even -)

It could be done. It would however be a pain to convert everything
from the current hard-coded assumption of a single delimiter, and
it would require an additional abstraction layer.

However when you increase the number of delimiters, you can also
increase the number of table lookups.

        Wietse

> p.s there's another good reason for me: my address is [hidden email] which  
> is too short for many sites... so I usually then use e
> +[hidden email] which allows me to know, when I get spam at that  
> address, where my address was stolen from.
Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Erick Calder
On Sep 25, 2009, at 12:20 PM, Wietse Venema wrote:

> Erick Calder:
>
>> this brings to mind: I've long used plussed addresses and love that
>> feature but my only complaint is that many systems disallow the +  
>> sign
>> in an e-mail address... is there a way to have a character bag work  
>> as
>> the delimiter? i.e. any of a list of characters? (obviously a dot "."
>> could also serve well as a delimiter since it's well accepted... but
>> not as nice as + or /, or even -)
>
> It could be done. It would however be a pain to convert everything
> from the current hard-coded assumption of a single delimiter, and
> it would require an additional abstraction layer.
>
> However when you increase the number of delimiters, you can also
> increase the number of table lookups.

I don't think it would be so difficult.  when the mail arrives, the  
local part of the address gets scanned for a set of characters (easy  
regex) and replaced with whatever postfix currently recognises as the  
delimiter.  this way as far as postfix is concerned, there is still  
only 1 delimiter.  of course, this assumes the user isn't going to  
segregate mail based on the delimiters (but I think that's fine)
Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Wietse Venema
Erick Calder:

> On Sep 25, 2009, at 12:20 PM, Wietse Venema wrote:
>
> > Erick Calder:
> >
> >> this brings to mind: I've long used plussed addresses and love that
> >> feature but my only complaint is that many systems disallow the +  
> >> sign
> >> in an e-mail address... is there a way to have a character bag work  
> >> as
> >> the delimiter? i.e. any of a list of characters? (obviously a dot "."
> >> could also serve well as a delimiter since it's well accepted... but
> >> not as nice as + or /, or even -)
> >
> > It could be done. It would however be a pain to convert everything
> > from the current hard-coded assumption of a single delimiter, and
> > it would require an additional abstraction layer.
> >
> > However when you increase the number of delimiters, you can also
> > increase the number of table lookups.
>
> I don't think it would be so difficult.  when the mail arrives, the  
> local part of the address gets scanned for a set of characters (easy  
> regex) and replaced with whatever postfix currently recognises as the  
> delimiter.  this way as far as postfix is concerned, there is still  
> only 1 delimiter.  of course, this assumes the user isn't going to  
> segregate mail based on the delimiters (but I think that's fine)

You can't replace the delimiter. That would break other people's
transit mail, among many things.

What if one address matches more than one element in your delimiter
set?  How do you know which one the author of the email address
intended to use? Postfix would have to try each alternative with
its virtual alias, canonical etc. lookups.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Erick Calder
On Sep 25, 2009, at 2:30 PM, Wietse Venema wrote:

> Erick Calder:
>> On Sep 25, 2009, at 12:20 PM, Wietse Venema wrote:
>>
>>> Erick Calder:
>>>
>>>> this brings to mind: I've long used plussed addresses and love that
>>>> feature but my only complaint is that many systems disallow the +
>>>> sign
>>>> in an e-mail address... is there a way to have a character bag work
>>>> as
>>>> the delimiter? i.e. any of a list of characters? (obviously a dot  
>>>> "."
>>>> could also serve well as a delimiter since it's well accepted...  
>>>> but
>>>> not as nice as + or /, or even -)
>>>
>>> It could be done. It would however be a pain to convert everything
>>> from the current hard-coded assumption of a single delimiter, and
>>> it would require an additional abstraction layer.
>>>
>>> However when you increase the number of delimiters, you can also
>>> increase the number of table lookups.
>>
>> I don't think it would be so difficult.  when the mail arrives, the
>> local part of the address gets scanned for a set of characters (easy
>> regex) and replaced with whatever postfix currently recognises as the
>> delimiter.  this way as far as postfix is concerned, there is still
>> only 1 delimiter.  of course, this assumes the user isn't going to
>> segregate mail based on the delimiters (but I think that's fine)
>
> You can't replace the delimiter. That would break other people's
> transit mail, among many things.

I'm not sure I understand... perhaps we're speaking of 2 different  
things.  what I mean is that when an e-mail first arrives at the  
server, before it gets processed, it could be rewritten to use the  
known delimiter i.e. a mail arriving for e/[hidden email] could be  
rewritten as [hidden email] (since + is what postfix uses to delimit)

> What if one address matches more than one element in your delimiter
> set?  How do you know which one the author of the email address
> intended to use? Postfix would have to try each alternative with
> its virtual alias, canonical etc. lookups.

take the first instance.  that's how postfix does it, isn't that the  
case?

Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Wietse Venema
Erick Calder:

> On Sep 25, 2009, at 2:30 PM, Wietse Venema wrote:
>
> > Erick Calder:
> >> On Sep 25, 2009, at 12:20 PM, Wietse Venema wrote:
> >>
> >>> Erick Calder:
> >>>
> >>>> this brings to mind: I've long used plussed addresses and love that
> >>>> feature but my only complaint is that many systems disallow the +
> >>>> sign
> >>>> in an e-mail address... is there a way to have a character bag work
> >>>> as
> >>>> the delimiter? i.e. any of a list of characters? (obviously a dot  
> >>>> "."
> >>>> could also serve well as a delimiter since it's well accepted...  
> >>>> but
> >>>> not as nice as + or /, or even -)
> >>>
> >>> It could be done. It would however be a pain to convert everything
> >>> from the current hard-coded assumption of a single delimiter, and
> >>> it would require an additional abstraction layer.
> >>>
> >>> However when you increase the number of delimiters, you can also
> >>> increase the number of table lookups.
> >>
> >> I don't think it would be so difficult.  when the mail arrives, the
> >> local part of the address gets scanned for a set of characters (easy
> >> regex) and replaced with whatever postfix currently recognises as the
> >> delimiter.  this way as far as postfix is concerned, there is still
> >> only 1 delimiter.  of course, this assumes the user isn't going to
> >> segregate mail based on the delimiters (but I think that's fine)
> >
> > You can't replace the delimiter. That would break other people's
> > transit mail, among many things.
>
> I'm not sure I understand... perhaps we're speaking of 2 different  
> things.  what I mean is that when an e-mail first arrives at the  
> server, before it gets processed, it could be rewritten to use the  
> known delimiter i.e. a mail arriving for e/[hidden email] could be  
> rewritten as [hidden email] (since + is what postfix uses to delimit)

On an end-node server, you can use a regexp map in one of the Postfix
address rewriting features that already exist.

On an infrastructure server, can't replace the delimiter. That
would break other people's mail.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Erick Calder
On Sep 25, 2009, at 3:07 PM, Wietse Venema wrote:

> Erick Calder:
>> On Sep 25, 2009, at 2:30 PM, Wietse Venema wrote:

<snip>

>>> You can't replace the delimiter. That would break other people's
>>> transit mail, among many things.
>>
>> I'm not sure I understand... perhaps we're speaking of 2 different
>> things.  what I mean is that when an e-mail first arrives at the
>> server, before it gets processed, it could be rewritten to use the
>> known delimiter i.e. a mail arriving for e/[hidden email] could be
>> rewritten as [hidden email] (since + is what postfix uses to  
>> delimit)
>
> On an infrastructure server, can't replace the delimiter. That
> would break other people's mail.

oh, I think i get it.  if server A is just relaying to server B, it  
will get e/[hidden email] and hand [hidden email] to B.  I'm not sure  
I understand how that would break the mail (since [hidden email]) is  
valid and will still be received.  of course, if B is configured to  
use delimiter | then it will break since it will receive e
+[hidden email] when it expects e|[hidden email] - but that is easily  
fixed since server A knows whether it's relaying or delivering to a  
local account, no?  so the rewrite could happen for local deliveries  
only.

> On an end-node server, you can use a regexp map in one of the Postfix
> address rewriting features that already exist.

I figured there was already some such capability.  I'll need to  
research (for my own purposes)
Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

@lbutlr
In reply to this post by Wietse Venema
On Sep 25, 2009, at 15:30, [hidden email] (Wietse Venema) wrote:

> What if one address matches more than one element in your delimiter
> set?

Only match on the first delimited found, seems like the best idea.

[hidden email]

If the delimited is + then the extension is ext. If the delimiters  
are .-+ then the extension is extension-word+ext.

Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Barney Desmond
In reply to this post by Erick Calder
2009/9/26 Erick Calder <[hidden email]>:
> oh, I think i get it.  if server A is just relaying to server B, it will get
> e/[hidden email] and hand [hidden email] to B.  I'm not sure I understand
> how that would break the mail (since [hidden email]) is valid and will
> still be received.  of course, if B is configured to use delimiter | then it
> will break since it will receive [hidden email] when it expects
> e|[hidden email] - but that is easily fixed since server A knows whether it's
> relaying or delivering to a local account, no?  so the rewrite could happen
> for local deliveries only.

It sounds like you get it now, but you make too many assumptions of
the servers. Server A doesn't know what Server B expects and
understands, nor does it care. Server A *has* to pass on the original
address if it's relaying the mail. Server A knows whether it's
relaying or doing local-delivery, but it's still a bit messy, which is
the real point here.


LuKreme: sure, it's easy to describe the generally-expected behaviour,
but I suspect Wietse's point is that you're welcome to write the patch
and make sure nothing breaks. *grin*
Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

@lbutlr
On Sep 26, 2009, at 0:08, Barney Desmond <[hidden email]>  
wrote:

> LuKreme: sure, it's easy to describe the generally-expected behaviour,
> but I suspect Wietse's point is that you're welcome to write the patch
> and make sure nothing breaks. *grin*

Aye, there's the rub.

Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

mouss-4
In reply to this post by Erick Calder
Erick Calder wrote:

> On Sep 25, 2009, at 3:07 PM, Wietse Venema wrote:
>
>> Erick Calder:
>>> On Sep 25, 2009, at 2:30 PM, Wietse Venema wrote:
>
> <snip>
>
>>>> You can't replace the delimiter. That would break other people's
>>>> transit mail, among many things.
>>>
>>> I'm not sure I understand... perhaps we're speaking of 2 different
>>> things.  what I mean is that when an e-mail first arrives at the
>>> server, before it gets processed, it could be rewritten to use the
>>> known delimiter i.e. a mail arriving for e/[hidden email] could be
>>> rewritten as [hidden email] (since + is what postfix uses to delimit)
>>
>> On an infrastructure server, can't replace the delimiter. That
>> would break other people's mail.
>
> oh, I think i get it.  if server A is just relaying to server B, it will
> get e/[hidden email] and hand [hidden email] to B.  I'm not sure I
> understand how that would break the mail (since [hidden email]) is
> valid and will still be received.  of course, if B is configured to use
> delimiter | then it will break since it will receive [hidden email]
> when it expects e|[hidden email] - but that is easily fixed since server
> A knows whether it's relaying or delivering to a local account, no?  so
> the rewrite could happen for local deliveries only.
>
>> On an end-node server, you can use a regexp map in one of the Postfix
>> address rewriting features that already exist.
>
> I figured there was already some such capability.  I'll need to research
> (for my own purposes)



== virtual_alias_maps:

/^(joe|jim|jane)-(.*)@(example\.net|example\.com)$/    $1+$2@$3

this converts [hidden email] to [hidden email]

If you don't want to generate the file (and update it when you add
users), you can use mysql or friends.

PS. in your examples, you use '/' and '|'. but those sites that refuse
'+' won't accept these either.




Reply | Threaded
Open this post in threaded view
|

Re: Semi-OT: recipient delimiter spec/std?

Erick Calder
On Sep 26, 2009, at 12:30 PM, mouss wrote:

> <snip>
>
> == virtual_alias_maps:
>
> /^(joe|jim|jane)-(.*)@(example\.net|example\.com)$/    $1+$2@$3
>
> this converts [hidden email] to [hidden email]
>
> If you don't want to generate the file (and update it when you add
> users), you can use mysql or friends.
>
> PS. in your examples, you use '/' and '|'. but those sites that refuse
> '+' won't accept these either.

yeah, I tried : too but it confuses the headers :) but a dot, dash or  
underscore are all pretty safe