Re: New User: Locking file issue and other bits [Part 2]

More than you never wanted to know...

I've bcc'd this to his kreminess using a plussed address.  he can examine 
his mail headers on the extra copy (if it arrives) to see how his system 
supports it.  Alternatively, he won't receive an extra copy, and I'll 
instead get a nouser bounce.
At 18:49 2003-02-06 -0700, Kremey-but-not-Krispy did ask:

> Where can I find more information on this "plussing" of email 
> addresses?  I've seen it mentioned in passing, but that's about it...
Uhm, head to <http://www.procmail.org> and follow the links to the FAQs?

Jari Aalto's PM-TIPS has, under 11.2, a section on plussed addressing.

PM-TIPS 11.3 discusses a comment trick, but that relies on the MUA of the 
person sending you email to actually retain the comment fields, and has 
trouble when someone elects to just enter the "address-looking" part of 
your address, sans the obvious comment (name) field.  It also breaks when 
you are addressed via BCC (such as on mailing lists), and even mailing 
lists which send out individual personally-addressed messages typically 
scrub the s*bscriber address of its comment, so it is little more than an 
iffy kludge that at best works "sometimes" under specific conditions.
Technically the following is valid per-spec:

        kremels(procmail)@kreme.com
or even:
        kremels@(procmail)kreme.com     (allowed, but I wouldn't recommend it)

Though your MTA will likely rewrite these when the message passes through, 
becoming:
        kremels(_at_)kreme(_dot_)com (procmail)

But, if you specify your email address in a reply-to with the first syntax, 
it _may_ retain that format (until the replied-to address is handled at 
your mailserver and the local part is parsed for local delivery).  The idea 
here is that you'd have a predictable comment portion.

If you want to get into specifics, start with the email address 
specification, RFC 822, which was superceeded by RFC 2822.  See RFC 2822. § 
3.4.1 for the meat of addr-spec.

Unlike the rather limited comment addressing above (which I'd never 
recommend anyway, but it's fun to see what the mail server does with a 
funky looking address according to the spec) plussed addressing has the 
benefit of appearing to be a regular email address and not being 
interpreted as a comment.  The MTA doesn't shuffle around the plussed 
portion, it merely ignores it when parsing out the local username to 
determine the account for local delivery.
It is _EXTREMELY_ useful for managing bounces on a mailing list, since you 
can deliver a message with a return path like so:
        
listbounces+recipientaddress-with-some-tokens-escaped(_at_)listdomain(_dot_)tld

Which permits you to have just _one_ alias for the bounce processor (per 
list, although the listname could be encoded into the plussed portion as 
well) which then takes the plussed portion and unescapes it to determine 
the s*bscribed address which bounced (since many bounces don't contain an 
easily parseable subscriber address, or may bounce with an address which 
was ultimatley forwarded to).  ez-mlm (mailing list manager, not 
multi-level-marketing) uses this technique.  It's very useful even on lists 
which normally don't send out the messages with such unique addressing 
(which is inefficient to say the least - if you've got 500 users at one 
domain, you'd rather send ONE message there with 500 recipients rather than 
500 separate messages), by processing the subscriber list with a "list 
s*bscription probe" (being a message containing useful list pointers and 
reminders of how to get on and off a list, for instance) using this 
technique, and managing the collective bounces.
Whether your MTA is actually standards compliant is another matter 
entirely.  There is way too much schlockware out there (read: anything 
running on a Windowz box) that can't follow a standard as it is.  The LHS 
should need to be parsed only by the system identified by the RHS, so as 
long as the comments are properly handled by the MTA at the recipient 
machine, all the intermediate hosts which handle the message shouldn't have 
too much trouble with it, because they shouldn't even be parsing the LHS in 
the first place!
I'm surprised more people don't know about plussing.  Heck, several people 
here on this forum use it regularly.  I use it extensively outside of this 
forum (the only reason that I don't use it here is that I never chose to 
change my email address here when I adopted plussing on other forums).
Also, plussing has a beneficial side effect: some viruses (such as Klez) 
have braindead address parsers which misparse the plussed portion when 
schlepping addresses, and therefore end up extracting an address as:
        "whatever(_at_)host(_dot_)domain(_dot_)tld"

Which, so long as you don't have an account at _that_ address (versus 
username(_at_)host(_dot_)domain(_dot_)tld), results in the virus deliveries bouncing during 
the SMTP recipient resolution stage (meaning that the BODY of the virus 
message is never delivered across your network connection).  I reported on 
this some months back (well, perhaps back in March or so of last year when 
Klez and its ilk started making the rounds, and I noted an interesting 
increase in the number of rejected messages on my server, and the addresses 
which were being used).
Plussed addressing has two downsides (which one should keep in mind are 
really non-issues anyway) that I'm aware of:
        1. Some braindead (and generally archaic) MUAs fail to follow the
        mail addressing RFC and don't comprehend the + portion.  cc:Mail
        is one such program.  Basically, the *SENDER* has no friggin' business
        interpreting the local part, but these apps do.  It is rare for me
        to have problems with people sending messages to my plussed address.

        2. the plussed address still resolves to your one physical address,
        so if you have 20 different plussed addresses, they all come through
        your one account - this is great - except that since the SENDER isn't
        supposed to interpret the local portion, a *SPAMBOT* can harvest a
        dozen variations on your address (from different sources), scrub their
        list for duplicates (user+one(_at_)domain and user+two(_at_)domain will 
be
        interpreted to be SEPARATE addresses, as they should be), and you'll
        still receive multiple copies.  However, this is really no different
        than if you were using multiple separate PHYSICAL mailbox addresses,
        so it shouldn't be viewed as a real handycap to using plussed
        addresses.

There is a third: your ISP may not support plussing at all.  That's easy 
enough to verify: send yourself a message with a plussed portion.

The sendmail documentation covers plussed users in § 24.4.3 (Sendmail 8.7 
and above, which you should darn well hope your ISP has long since upgraded 
from anyway).  Plussing is supported for _aliases_, so it is possible to 
take a given plussed address and discontinue it, bouncing the bugger 
(assuming you have control over the mail server configuration), like so:
user(_at_)host(_dot_)domain(_dot_)tld            reallocaluser
user+discontinued(_at_)host(_dot_)domain(_dot_)tld       ERROR:5.1.1:550 User 
unknown

Which is a great way to allow you to use _one_ physical account without a 
lot of configuration overhead, but when you eventually have control over 
your mail server, you can graduate to selectively rejecting some addressees 
(say, because some s*bscription list got raided and added to a spam db).
I really hate _receiving_ the spew _then_ discarding it -- whenever 
possible, I try to reject spew before I've had to take the network hit for 
transferring the body of the spew (which can sometimes be rather 
significant, moreso for some fool^H^H^H^H user running over analog 
dialup).  If you can do that, you seriously minimize the impact of email abuse.

FTR, I have a PDF file I maintain with various RFCs, STDs, and BCPs which I 
make regular references to. <http://www.faqs.org/> is s repository of such 
documents and also includes an archive of newsgroup and other FAQs.  Having 
them in a reference file keeps them at arms reach, and organized to include 
those specific RFCs which I refer to often.
---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail