use sed extract username from email address

Hi,

does anyone know how to use sed extract the username from a email address?
eg. if email address is jsimpson@xyz.com
I want to extract jsimpson from the address.

Thanks
S

Re: use sed extract username from email address

In news:S0irh.26527$b6.237457@nasal.pacific.net.au,
Pet Farrari wrote:

> does anyone know how to use sed extract the username from a email
> address? eg. if email address is jsimpson@xyz.com
> I want to extract jsimpson from the address.

cut -d "@" -f1
awk -F"@" '{print $1}'
sed -e 's|@xyz\.com||'

Re: use sed extract username from email address

patrick wrote:
> In news:S0irh.26527$b6.237457@nasal.pacific.net.au,
> Pet Farrari wrote:
>
>> does anyone know how to use sed extract the username from a email
>> address? eg. if email address is jsimpson@xyz.com
>> I want to extract jsimpson from the address.
>
> cut -d "@" -f1
> awk -F"@" '{print $1}'
> sed -e 's|@xyz\.com||'
>
Unfortunately, the domain name will change all the time.
can I do it like this:


cut -d "@" -f1
awk -F"@" '{print $1}'
username=sed -e 's|@*||'

This will be used in a script or in procmail rc file.

Thanks
S

Re: use sed extract username from email address

Pet Farrari wrote:
> patrick wrote:
>> In news:S0irh.26527$b6.237457@nasal.pacific.net.au,
>> Pet Farrari wrote:
>>
>>> does anyone know how to use sed extract the username from a email
>>> address? eg. if email address is jsimpson@xyz.com
>>> I want to extract jsimpson from the address.
>>
>> cut -d "@" -f1
>> awk -F"@" '{print $1}'
>> sed -e 's|@xyz\.com||'
>>
> Unfortunately, the domain name will change all the time.
> can I do it like this:
>
>
> cut -d "@" -f1
> awk -F"@" '{print $1}'
> username=sed -e 's|@*||'
>
> This will be used in a script or in procmail rc file.
>

SpamBouncer (by Catherine Hampton) has email header extraction recipes
in it that use sed for this and other purposes. I recommend you go study
that code base. No sense re-inventing the wheel if you don't have to.

IMHO, Anything in procmail that calls an external program you should try
to first get working on the command line before trying to use it in a
procmail recipe. It'll make your debugging much easier in the long run.

--
Garen

Re: use sed extract username from email address

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-16438-1169035512-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Pet Farrari writes:

> Hi,
>
> does anyone know how to use sed extract the username from a email address?
> eg. if email address is jsimpson@xyz.com
> I want to extract jsimpson from the address.

There are many ways to format E-mail addresses. sed is not enough to
properly parse all possible variations of representing E-mail addresses. I
do not recall any convenient tool that can be used to pull out the
individual E-mail addresses, in that manner.

You'll probably have to write something yourself.


--=_mimegpg-commodore.email-scan.com-16438-1169035512-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBFrhD4x9p3GYHlUOIRAh2qAJ9ZAJAg8mOiazDFExKucXNhs5slDQCf TX5F
xRnYP4srsYSEztQyGairWBE=
=krWA
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-16438-1169035512-0002--

Re: use sed extract username from email address

Hi!

> Unfortunately, the domain name will change all the time.
> can I do it like this:
>
>
> cut -d "@" -f1
> awk -F"@" '{print $1}'
> username=sed -e 's|@*||'

Why don't you just try it yourself?

The first and the second one will give you everything in front of the
first @.

Used on abc@def.gh@ijk.lm, they will return abc.

The third one is wrong. @* means any number of @ in a row:
'', '@', '@@', '@@@' and so on. This one would do:

sed -e 's|@.*||'

Substitute @followedbywhatever with nothing.

If you can choose, take the cut:

USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`

greez

Mario

Re: use sed extract username from email address

Garen Erdoisa wrote:
> Pet Farrari wrote:
>> patrick wrote:
>>> In news:S0irh.26527$b6.237457@nasal.pacific.net.au,
>>> Pet Farrari wrote:
>>>
>>>> does anyone know how to use sed extract the username from a email
>>>> address? eg. if email address is jsimpson@xyz.com
>>>> I want to extract jsimpson from the address.
>>>
>>> cut -d "@" -f1
>>> awk -F"@" '{print $1}'
>>> sed -e 's|@xyz\.com||'
>>>
>> Unfortunately, the domain name will change all the time.
>> can I do it like this:
>>
>>
>> cut -d "@" -f1
>> awk -F"@" '{print $1}'
>> username=sed -e 's|@*||'
>>
>> This will be used in a script or in procmail rc file.
>>
>
> SpamBouncer (by Catherine Hampton) has email header extraction recipes
> in it that use sed for this and other purposes. I recommend you go study
> that code base. No sense re-inventing the wheel if you don't have to.
>
> IMHO, Anything in procmail that calls an external program you should try
> to first get working on the command line before trying to use it in a
> procmail recipe. It'll make your debugging much easier in the long run.
>
Just looked at it, but too much information to dig into,
Thanks
S

Re: use sed extract username from email address

mario.lenz@gmx.net wrote:
> Hi!
>
>> Unfortunately, the domain name will change all the time.
>> can I do it like this:
>>
>>
>> cut -d "@" -f1
>> awk -F"@" '{print $1}'
>> username=sed -e 's|@*||'
>
> Why don't you just try it yourself?
>
> The first and the second one will give you everything in front of the
> first @.
>
> Used on abc@def.gh@ijk.lm, they will return abc.
>
> The third one is wrong. @* means any number of @ in a row:
> '', '@', '@@', '@@@' and so on. This one would do:
>
> sed -e 's|@.*||'
>
> Substitute @followedbywhatever with nothing.
>
> If you can choose, take the cut:
>
> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
>
What about to get the username and the domainname?
I need to use both in procmail rc file:
|deliver -r ${username}@${domainname} ${username}/Trash .

Can I write something as follow to achieve that?
USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`

Thanks
S

> greez
>
> Mario
>

Re: use sed extract username from email address

In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
Pet Farrari wrote:

> Can I write something as follow to achieve that?
> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
> DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`

Is there some reason that you can't try things for yourself?

Re: use sed extract username from email address

patrick wrote:
> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
> Pet Farrari wrote:
>
>> Can I write something as follow to achieve that?
>> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
>> DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`
>
> Is there some reason that you can't try things for yourself?
>
>
yup, just test it, it works.
Thanks
S

Re: use sed extract username from email address

On 2007-01-17, Pet Farrari wrote:
> Hi,
>
> does anyone know how to use sed extract the username from a email address?
> eg. if email address is jsimpson@xyz.com
> I want to extract jsimpson from the address.

In any POSIX shell:

email=jsimpson@example.com
username=${email%@*}
domain=${email#*@}

--
Chris F.A. Johnson, author |
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence

Re: use sed extract username from email address

Pet Farrari wrote:
> patrick wrote:
>> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
>> Pet Farrari wrote:
>>
>>> Can I write something as follow to achieve that?
>>> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
>>> DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`
>>
>> Is there some reason that you can't try things for yourself?
>>
>>
> yup, just test it, it works.
> Thanks
> S

IMHO:

I'd like jump in and point out here that the To: and Cc: header lines
can be easily forged during the SMTP transaction. It's given as part of
the BODY information during an SMTP transaction which to the server is
just data. As long as the SMTP RCPT TO: (or envelope recipient)
information is valid then an attempt will be made by the server to
deliver the email to that address regardless of the contents of any
other To: or Cc: headers given in the SMTP message DATA. Quite often the
final recipient is listed nowhere in the To: or Cc: headers, or anywhere
in any other headers or body of the email.

The analogy here is that if you stuff an envelope with the wrong letter.
The envelop will be delivered by the post office to the address on the
envelope without regard to the contents of the envelope.

The only thing I pay attention to in the To: or Cc: headers on email
servers I manage is if the information contained in the "real name
field" of any given To: or Cc: address is consistent with the "email
address" it's paired with, and then only if the email address is a valid
local recipient. Otherwise the contents of the To: and Cc: headers are
ignored.

If someone sends to randomly generated Real Names it's a sure fire spam
sign and very reliable for spam filtering just by itself.

It's a bit more work to set up an email address database where users can
specify a list of "real name" or "nickname" patterns that go along with
a particular email address and that anything else is to be considered
bogus or at least suspect.

So, with that said, IMHO the only address you should be paying attention
to for delivery in your procmail setup is the information passed to
procmail in the ${recipient} variable given on the procmail command line
when it's invoked by postfix. This is because you are dealing with
virtual users. If you were dealing with actual local accounts on the
server instead of virtual accounts in a cyrus imapd database then you
should be paying attention only to the contents of the LOGNAME and HOST
variables.

I would suggest that you ignore the contents of the To: or Cc: headers
completely, unless it's just for testing for bogus real names as part of
your spam filtering.

You could pay attention to the From: and or Return-Path: headers to
compare them vs a list of valid senders however. That is one form of
what is called white listing. In this case, any email containing a
whitelisted sender might with a few other simple tests be exempted from
further filtering other than say checking for virus, executable
attachments, or embedded executable links.

--
Regards
Garen

Re: use sed extract username from email address

Garen Erdoisa wrote:
> Pet Farrari wrote:
>> patrick wrote:
>>> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
>>> Pet Farrari wrote:
>>>
>>>> Can I write something as follow to achieve that?
>>>> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
>>>> DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`
>>>
>>> Is there some reason that you can't try things for yourself?
>>>
>>>
>> yup, just test it, it works.
>> Thanks
>> S
>
> IMHO:
>
> I'd like jump in and point out here that the To: and Cc: header lines
> can be easily forged during the SMTP transaction. It's given as part of
> the BODY information during an SMTP transaction which to the server is
> just data. As long as the SMTP RCPT TO: (or envelope recipient)
> information is valid then an attempt will be made by the server to
> deliver the email to that address regardless of the contents of any
> other To: or Cc: headers given in the SMTP message DATA. Quite often the
> final recipient is listed nowhere in the To: or Cc: headers, or anywhere
> in any other headers or body of the email.
>
> The analogy here is that if you stuff an envelope with the wrong letter.
> The envelop will be delivered by the post office to the address on the
> envelope without regard to the contents of the envelope.
>
> The only thing I pay attention to in the To: or Cc: headers on email
> servers I manage is if the information contained in the "real name
> field" of any given To: or Cc: address is consistent with the "email
> address" it's paired with, and then only if the email address is a valid
> local recipient. Otherwise the contents of the To: and Cc: headers are
> ignored.
>
> If someone sends to randomly generated Real Names it's a sure fire spam
> sign and very reliable for spam filtering just by itself.
>
> It's a bit more work to set up an email address database where users can
> specify a list of "real name" or "nickname" patterns that go along with
> a particular email address and that anything else is to be considered
> bogus or at least suspect.
>
> So, with that said, IMHO the only address you should be paying attention
> to for delivery in your procmail setup is the information passed to
> procmail in the ${recipient} variable given on the procmail command line
> when it's invoked by postfix. This is because you are dealing with
> virtual users. If you were dealing with actual local accounts on the
> server instead of virtual accounts in a cyrus imapd database then you
> should be paying attention only to the contents of the LOGNAME and HOST
> variables.
>
> I would suggest that you ignore the contents of the To: or Cc: headers
> completely, unless it's just for testing for bogus real names as part of
> your spam filtering.
>
> You could pay attention to the From: and or Return-Path: headers to
> compare them vs a list of valid senders however. That is one form of
> what is called white listing. In this case, any email containing a
> whitelisted sender might with a few other simple tests be exempted from
> further filtering other than say checking for virus, executable
> attachments, or embedded executable links.
>
Yes, I m totally agree with that. I will certainly test this further
later. Thanks.
S

Re: use sed extract username from email address

Garen Erdoisa wrote:
> Pet Farrari wrote:
>> patrick wrote:
>>> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
>>> Pet Farrari wrote:
>>>
>>>> Can I write something as follow to achieve that?
>>>> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
>>>> DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`
>>>
>>> Is there some reason that you can't try things for yourself?
>>>
>>>
>> yup, just test it, it works.
>> Thanks
>> S
>
> IMHO:
>
> I'd like jump in and point out here that the To: and Cc: header lines
> can be easily forged during the SMTP transaction. It's given as part of
> the BODY information during an SMTP transaction which to the server is
> just data. As long as the SMTP RCPT TO: (or envelope recipient)
> information is valid then an attempt will be made by the server to
> deliver the email to that address regardless of the contents of any
> other To: or Cc: headers given in the SMTP message DATA. Quite often the
> final recipient is listed nowhere in the To: or Cc: headers, or anywhere
> in any other headers or body of the email.
>
> The analogy here is that if you stuff an envelope with the wrong letter.
> The envelop will be delivered by the post office to the address on the
> envelope without regard to the contents of the envelope.
>
> The only thing I pay attention to in the To: or Cc: headers on email
> servers I manage is if the information contained in the "real name
> field" of any given To: or Cc: address is consistent with the "email
> address" it's paired with, and then only if the email address is a valid
> local recipient. Otherwise the contents of the To: and Cc: headers are
> ignored.
>
> If someone sends to randomly generated Real Names it's a sure fire spam
> sign and very reliable for spam filtering just by itself.
>
> It's a bit more work to set up an email address database where users can
> specify a list of "real name" or "nickname" patterns that go along with
> a particular email address and that anything else is to be considered
> bogus or at least suspect.
>
> So, with that said, IMHO the only address you should be paying attention
> to for delivery in your procmail setup is the information passed to
> procmail in the ${recipient} variable given on the procmail command line
> when it's invoked by postfix. This is because you are dealing with
> virtual users. If you were dealing with actual local accounts on the
> server instead of virtual accounts in a cyrus imapd database then you
> should be paying attention only to the contents of the LOGNAME and HOST
> variables.
>
> I would suggest that you ignore the contents of the To: or Cc: headers
> completely, unless it's just for testing for bogus real names as part of
> your spam filtering.
>
> You could pay attention to the From: and or Return-Path: headers to
> compare them vs a list of valid senders however. That is one form of
> what is called white listing. In this case, any email containing a
> whitelisted sender might with a few other simple tests be exempted from
> further filtering other than say checking for virus, executable
> attachments, or embedded executable links.
>

I just found out I still having problem with getting real name of the
recipent. ATM, if sender sends email to the virual name (or alias) of
the real email user name, the cyrus's deliver program will try to
deliver the email to the virtual name, and thus result in error, as my
procmail rc file said that if any error encountered, just deliver the
email by procmail ratehr than cyrus'deliver program, so the email gets
into my INBOX rather than get deliver to my Spam folder.

I still trying to figure out how to get the real email user name based
on the virtual name in procmail. Perhaps procmail itself has command I
can use?

Thanks
S

Re: use sed extract username from email address

Pet wrote:
> Garen Erdoisa wrote:
>> Pet Farrari wrote:
>>> patrick wrote:
>>>> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
>>>> Pet Farrari wrote:
>>>>
>>>>> Can I write something as follow to achieve that?
>>>>> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
>>>>> DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`
>>>>
>>>> Is there some reason that you can't try things for yourself?
>>>>
>>>>
>>> yup, just test it, it works.
>>> Thanks
>>> S
>>
>> [SNIP]
>>
>
> I just found out I still having problem with getting real name of the
> recipent. ATM, if sender sends email to the virual name (or alias) of
> the real email user name, the cyrus's deliver program will try to
> deliver the email to the virtual name, and thus result in error, as my
> procmail rc file said that if any error encountered, just deliver the
> email by procmail ratehr than cyrus'deliver program, so the email gets
> into my INBOX rather than get deliver to my Spam folder.
>
> I still trying to figure out how to get the real email user name based
> on the virtual name in procmail. Perhaps procmail itself has command I
> can use?
>

I've never really had that problem myself because I don't use virtual
user names as final destination recipients. The final destination
recipient on systems I manage are real user account names on that system.

However I do use virtual user names in the sendmail /etc/aliases file
that are mapped to real user accounts.

If I want to give a unique email address to a web site for their use as
an email contact address for instance, I make up a random set of letters
and numbers as the virtual email address, then use /etc/aliases to map
that over to my real address. Example:

askervk93424: sample

something like that.
Then when the site sends an email to

askervk93424@example.org

sendmail looks in /etc/aliases, finds the string

askervk93424

sees that it's mapped to sample, then delivers the email to
sample@example.org

In this case, when sendmail hands off the email to procmail, procmail
drops privileges and assumes the identity of the "sample" account, the
LOGNAME variable is set to "sample", while the To: header in the email
is left alone and usually is set to askervk93424@example.org

I can then use the ${HOME}/.procmailrc to look for that particular To:
header and file the email into an appropriate folder for that authorized
subscription email alias.

The procedure will also exempt that sender from any further spam
filtering in this particular case. If the sender gives away or sells the
email alias address, it's a simple matter to setup an access list entry
to deny any further emails sent to that email alias, then in my
discretion assign them a new alias to use, or not. Because I retain
records of who I give various alias addresses to, I also know who
compromised the alias so can have some ammunition that way to scold them
for giving it away or selling it.

Since adopting this procedure a couple of years ago, I've had only one
email address that was compromised in this fashion.

Email aliases are also useful for testing subscribe/unsubscribe
mechanisms to see if the owners of that particular mechanism honor their
own stated subscription and/or privacy policy or not.

Subscribe an alias, wait a month or so, unsubscribe the alias, then
subscribe another alias. Then wait an see if or how long it takes for
the unsubscribed alias to stop receiving email. Usually a week or two.

This procedure is useful for determining the hat color of any given
email sender if you care that much without affecting their provider in
any way.

So, that's how I do things on systems I manage.

In your case, you are using virtual accounts, with no real accounts. If
I were doing such a thing, I think I'd use a perl script with a hash
table to match incoming envelope recipient alias's to a valid virtual
account, then deliver the email to that valid virtual account. This
would be similar to the /etc/alias example given above.

If you had a case where the destination account was invalid, then that
could become a spamtrap address, or you could sink the email into
/dev/null, or send it to a catch all address, or whatever.

Better yet would be to reject invalid virtual accounts during the SMTP
transaction to inform the sender of the problem.

Of coarse, exposed contact addresses are subject to full filtering with
special procmail recipes in place to handle email from known senders etc
as previously discussed.

I'm not familiar with how postfix is configured. I would be surprised if
it can't do email aliases though. I would suggest that you look through
the postfix docs to see how to accomplish this.

--
Garen

Re: use sed extract username from email address

Garen Erdoisa wrote:
> Pet wrote:
>> Garen Erdoisa wrote:
>>> Pet Farrari wrote:
>>>> patrick wrote:
>>>>> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
>>>>> Pet Farrari wrote:
>>>>>
>>>>>> Can I write something as follow to achieve that?
>>>>>> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
>>>>>> DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`
>>>>>
>>>>> Is there some reason that you can't try things for yourself?
>>>>>
>>>>>
>>>> yup, just test it, it works.
>>>> Thanks
>>>> S
>>>
>>> [SNIP]
>>>
>>
>> I just found out I still having problem with getting real name of the
>> recipent. ATM, if sender sends email to the virual name (or alias) of
>> the real email user name, the cyrus's deliver program will try to
>> deliver the email to the virtual name, and thus result in error, as my
>> procmail rc file said that if any error encountered, just deliver the
>> email by procmail ratehr than cyrus'deliver program, so the email gets
>> into my INBOX rather than get deliver to my Spam folder.
>>
>> I still trying to figure out how to get the real email user name based
>> on the virtual name in procmail. Perhaps procmail itself has command I
>> can use?
>>
>
> I've never really had that problem myself because I don't use virtual
> user names as final destination recipients. The final destination
> recipient on systems I manage are real user account names on that system.
>
> However I do use virtual user names in the sendmail /etc/aliases file
> that are mapped to real user accounts.
>
> If I want to give a unique email address to a web site for their use as
> an email contact address for instance, I make up a random set of letters
> and numbers as the virtual email address, then use /etc/aliases to map
> that over to my real address. Example:
>
> askervk93424: sample
>
> something like that.
> Then when the site sends an email to
>
> askervk93424@example.org
>
> sendmail looks in /etc/aliases, finds the string
>
> askervk93424
>
> sees that it's mapped to sample, then delivers the email to
> sample@example.org
>
> In this case, when sendmail hands off the email to procmail, procmail
> drops privileges and assumes the identity of the "sample" account, the
> LOGNAME variable is set to "sample", while the To: header in the email
> is left alone and usually is set to askervk93424@example.org
>
Hi, I am actually using /etc/alias like sendmail does. I should write it
as alias not virtual. But how to assign the real username of the
recipent into the LOGNAME? I assumed you pass the value of the real user
to the LOGNAME in procmail.rc?

Thanks
S

> I can then use the ${HOME}/.procmailrc to look for that particular To:
> header and file the email into an appropriate folder for that authorized
> subscription email alias.
>
> The procedure will also exempt that sender from any further spam
> filtering in this particular case. If the sender gives away or sells the
> email alias address, it's a simple matter to setup an access list entry
> to deny any further emails sent to that email alias, then in my
> discretion assign them a new alias to use, or not. Because I retain
> records of who I give various alias addresses to, I also know who
> compromised the alias so can have some ammunition that way to scold them
> for giving it away or selling it.
>
> Since adopting this procedure a couple of years ago, I've had only one
> email address that was compromised in this fashion.
>
> Email aliases are also useful for testing subscribe/unsubscribe
> mechanisms to see if the owners of that particular mechanism honor their
> own stated subscription and/or privacy policy or not.
>
> Subscribe an alias, wait a month or so, unsubscribe the alias, then
> subscribe another alias. Then wait an see if or how long it takes for
> the unsubscribed alias to stop receiving email. Usually a week or two.
>
> This procedure is useful for determining the hat color of any given
> email sender if you care that much without affecting their provider in
> any way.
>
> So, that's how I do things on systems I manage.
>
> In your case, you are using virtual accounts, with no real accounts. If
> I were doing such a thing, I think I'd use a perl script with a hash
> table to match incoming envelope recipient alias's to a valid virtual
> account, then deliver the email to that valid virtual account. This
> would be similar to the /etc/alias example given above.
>
> If you had a case where the destination account was invalid, then that
> could become a spamtrap address, or you could sink the email into
> /dev/null, or send it to a catch all address, or whatever.
>
> Better yet would be to reject invalid virtual accounts during the SMTP
> transaction to inform the sender of the problem.
>
> Of coarse, exposed contact addresses are subject to full filtering with
> special procmail recipes in place to handle email from known senders etc
> as previously discussed.
>
> I'm not familiar with how postfix is configured. I would be surprised if
> it can't do email aliases though. I would suggest that you look through
> the postfix docs to see how to accomplish this.
>

Re: use sed extract username from email address

Pet wrote:
> Garen Erdoisa wrote:
>> Pet wrote:
>>> Garen Erdoisa wrote:
>>>> Pet Farrari wrote:
>>>>> patrick wrote:
>>>>>> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
>>>>>> Pet Farrari wrote:
>>>>>>
>>>>>>> Can I write something as follow to achieve that?
>>>>>>> USERNAME=`echo $MAILADDRESS | cut -d "@" -f1`
>>>>>>> DOMAINNAME=`echo $MAILADDRESS | cut -d "@" -f2`
>>>>>>
>>>>>> Is there some reason that you can't try things for yourself?
>>>>>>
>>>>>>
>>>>> yup, just test it, it works.
>>>>> Thanks
>>>>> S
>>>>
>>>> [SNIP]
>>>>
>>>
>>> I just found out I still having problem with getting real name of the
>>> recipent. ATM, if sender sends email to the virual name (or alias) of
>>> the real email user name, the cyrus's deliver program will try to
>>> deliver the email to the virtual name, and thus result in error, as
>>> my procmail rc file said that if any error encountered, just deliver
>>> the email by procmail ratehr than cyrus'deliver program, so the email
>>> gets into my INBOX rather than get deliver to my Spam folder.
>>>
>>> I still trying to figure out how to get the real email user name
>>> based on the virtual name in procmail. Perhaps procmail itself has
>>> command I can use?
>>>
>>
>> I've never really had that problem myself because I don't use virtual
>> user names as final destination recipients. The final destination
>> recipient on systems I manage are real user account names on that system.
>>
>> However I do use virtual user names in the sendmail /etc/aliases file
>> that are mapped to real user accounts.
>>
>> If I want to give a unique email address to a web site for their use
>> as an email contact address for instance, I make up a random set of
>> letters and numbers as the virtual email address, then use
>> /etc/aliases to map that over to my real address. Example:
>>
>> askervk93424: sample
>>
>> something like that.
>> Then when the site sends an email to
>>
>> askervk93424@example.org
>>
>> sendmail looks in /etc/aliases, finds the string
>>
>> askervk93424
>>
>> sees that it's mapped to sample, then delivers the email to
>> sample@example.org
>>
>> In this case, when sendmail hands off the email to procmail, procmail
>> drops privileges and assumes the identity of the "sample" account, the
>> LOGNAME variable is set to "sample", while the To: header in the
>> email is left alone and usually is set to askervk93424@example.org
>>
> Hi, I am actually using /etc/alias like sendmail does. I should write it
> as alias not virtual. But how to assign the real username of the
> recipent into the LOGNAME? I assumed you pass the value of the real user
> to the LOGNAME in procmail.rc?
>
If you meant the LOGNAME is what make up the folder name in imap
directory, my question should be revised to how to convert the alias
name to match the LOGNAME on the fly? I have a database table host the
mapping of alias -> LOGNAME, but I don[t want to involve database for
each incoming email... that will be slow down the email process alot alot.

Thanks
Sam

> Thanks
> S
>
>> I can then use the ${HOME}/.procmailrc to look for that particular To:
>> header and file the email into an appropriate folder for that
>> authorized subscription email alias.
>>
>> The procedure will also exempt that sender from any further spam
>> filtering in this particular case. If the sender gives away or sells
>> the email alias address, it's a simple matter to setup an access list
>> entry to deny any further emails sent to that email alias, then in my
>> discretion assign them a new alias to use, or not. Because I retain
>> records of who I give various alias addresses to, I also know who
>> compromised the alias so can have some ammunition that way to scold
>> them for giving it away or selling it.
>>
>> Since adopting this procedure a couple of years ago, I've had only one
>> email address that was compromised in this fashion.
>>
>> Email aliases are also useful for testing subscribe/unsubscribe
>> mechanisms to see if the owners of that particular mechanism honor
>> their own stated subscription and/or privacy policy or not.
>>
>> Subscribe an alias, wait a month or so, unsubscribe the alias, then
>> subscribe another alias. Then wait an see if or how long it takes for
>> the unsubscribed alias to stop receiving email. Usually a week or two.
>>
>> This procedure is useful for determining the hat color of any given
>> email sender if you care that much without affecting their provider in
>> any way.
>>
>> So, that's how I do things on systems I manage.
>>
>> In your case, you are using virtual accounts, with no real accounts.
>> If I were doing such a thing, I think I'd use a perl script with a
>> hash table to match incoming envelope recipient alias's to a valid
>> virtual account, then deliver the email to that valid virtual account.
>> This would be similar to the /etc/alias example given above.
>>
>> If you had a case where the destination account was invalid, then that
>> could become a spamtrap address, or you could sink the email into
>> /dev/null, or send it to a catch all address, or whatever.
>>
>> Better yet would be to reject invalid virtual accounts during the SMTP
>> transaction to inform the sender of the problem.
>>
>> Of coarse, exposed contact addresses are subject to full filtering
>> with special procmail recipes in place to handle email from known
>> senders etc as previously discussed.
>>
>> I'm not familiar with how postfix is configured. I would be surprised
>> if it can't do email aliases though. I would suggest that you look
>> through the postfix docs to see how to accomplish this.
>>

Re: use sed extract username from email address

On Wed, 17 Jan 2007 23:13:03 -0700, Garen Erdoisa
wrote:

>So, with that said, IMHO the only address you should be paying attention
>to for delivery in your procmail setup is the information passed to
>procmail in the ${recipient} variable given on the procmail command line
>when it's invoked by postfix.

I was under the impression that procmail didn't have access to the
envelope information. Is that true when I invoke procmail as a user via
..procmailrc in my home directory?

--
Steve Baker

Re: use sed extract username from email address

Steve Baker wrote:
> On Wed, 17 Jan 2007 23:13:03 -0700, Garen Erdoisa
> wrote:
>
>> So, with that said, IMHO the only address you should be paying attention
>> to for delivery in your procmail setup is the information passed to
>> procmail in the ${recipient} variable given on the procmail command line
>> when it's invoked by postfix.
>
> I was under the impression that procmail didn't have access to the
> envelope information. Is that true when I invoke procmail as a user via
> .procmailrc in my home directory?
>

It depends on your setup. You can pass whatever information you wish to
procmail via command line arguments. You can then extract that
information from inside your procmail recipes.

It's usually unnecessary though. The final destination recipient is in
effect the envelope recipient. That information is normally stored in
the LOGNAME environment variable. The envelope sender is normally found
on the From header line (the From header without the colon in Berkley
mailbox format) and can usually also be found in the Return-Path: header
as well. However since these headers are easily forged it's not really
that useful or interesting to look at except perhaps for white listing
purposes.

In this case the OP isn't using real accounts on his system, he's using
virtual accounts stored in a database, which poses a bit of a problem
since the LOGNAME variable in his case will always be root or cyrus. The
final destination recipient needs to be passed to procmail in some other
fashion, so in his case he's passing it to procmail as a command line
argument, then extracting that information in his procmail recipes for
later use.

--
Garen

Re: use sed extract username from email address

Pet wrote:
> Garen Erdoisa wrote:
>> Pet wrote:
>>> Garen Erdoisa wrote:
>>>> Pet Farrari wrote:
>>>>> patrick wrote:
>>>>>> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
>>>>>> Pet Farrari wrote:
>>>>>>
>>
>> [SNIP]
>> In this case, when sendmail hands off the email to procmail, procmail
>> drops privileges and assumes the identity of the "sample" account, the
>> LOGNAME variable is set to "sample", while the To: header in the
>> email is left alone and usually is set to askervk93424@example.org
>>
> Hi, I am actually using /etc/alias like sendmail does. I should write it
> as alias not virtual. But how to assign the real username of the
> recipent into the LOGNAME? I assumed you pass the value of the real user
> to the LOGNAME in procmail.rc?

LOGNAME is an environment variable that is assigned by the system. If
you have real user accounts, then when an email is sent to a real user
account on your system, the system will set this variable when procmail
drops privileges.

Your case is different because you are using virtual accounts for
delivery targets instead of real user accounts. So if or when procmail
drops privileges, the LOGNAME will be set by the system to that of the
cyrus user account which is useless for final email delivery to your
virtual user accounts.

In your case you need to use some *other* method for determining the
final recipient in your email database which I'm assuming you finally
solved by passing that information to procmail on the command line.

Since you also want to use email aliases mapped to virtual accounts, you
now have a new problem. That of determining which aliases are mapped to
a virtual account. In your particular case I don't think that using
/etc/aliases is going to work very well for you. Instead I would suggest
that you use a perl script or something along those lines to read a hash
table which when you pass an alias to that perl script will do the
lookup and return the virtual account it should deliver the email to. If
you can do this as a milter before procmail is invoked that may be best.
Then you could pass all the necessary information to procmail via
command line arguments.

If there is no match in your database, then you need to either bounce
the email, or sink it in /dev/null or deliver it to a catchall address.

Bouncing the email in this case is a *bad* idea. It would make your
system basically an open relay since anyone could then forge a return
path address, and send to a non-existent account on your system which
could bounce the email to an innocent third party.

You could use your SMTP access list to reject email during the SMTP
transaction for accounts you don't manage. Real or aliased. This would
be the option I would pursue if I were doing this.

This option would require that every virtual address and every alias
that mapped to a virtual address would need to be mapped into your
access list as a valid recipient. This could get rather unwieldy if your
database grows large enough, but it's better than bouncing the email, or
losing emails.

You might also look through your postfix docs to see if there is any
provision for setting up a virtual user table. That might solve a bunch
of problems if this is supported in postfix.

Since I don't use postfix, I just don't know for sure what it can do.

>> [SNIP]

--
Garen

Re: use sed extract username from email address

Pet wrote:
> Pet wrote:
>> Garen Erdoisa wrote:
>>> Pet wrote:
>>>> Garen Erdoisa wrote:
>>>>> Pet Farrari wrote:
>>>>>> patrick wrote:
>>>>>>> In news:22xrh.26540$b6.237851@nasal.pacific.net.au,
>>>>>>> Pet Farrari wrote:
>>>>>>>
>>>[SNIP]
> If you meant the LOGNAME is what make up the folder name in imap
> directory, my question should be revised to how to convert the alias
> name to match the LOGNAME on the fly?

Nope, already addressed this in my comments on your previous post.
LOGNAME is just an environment variable set by the system. It maps to a
real user account on the system.

> I have a database table host the
> mapping of alias -> LOGNAME, but I don[t want to involve database for
> each incoming email... that will be slow down the email process alot alot.
>

Yes, it will slow down the process a bit and eat CPU cycles. However you
can't have it both ways. If you want to do virtual users instead of real
users you have to use a database. If you also want to add aliases mapped
to your virtual users, that's yet another database. If you invent a way
to do this without using a database, you could probably make a fortune. :)

There are ways you can design databases to do extremely fast lookups.
But that's a whole other issue.

> [SNIP]

--
Garen

Re: use sed extract username from email address

On Fri, 19 Jan 2007 20:32:03 -0700, Garen Erdoisa
wrote:

>Steve Baker wrote:
>> On Wed, 17 Jan 2007 23:13:03 -0700, Garen Erdoisa
>> wrote:
>>
>>> So, with that said, IMHO the only address you should be paying attention
>>> to for delivery in your procmail setup is the information passed to
>>> procmail in the ${recipient} variable given on the procmail command line
>>> when it's invoked by postfix.
>>
>> I was under the impression that procmail didn't have access to the
>> envelope information. Is that true when I invoke procmail as a user via
>> .procmailrc in my home directory?
>>
>
>It depends on your setup. You can pass whatever information you wish to
>procmail via command line arguments. You can then extract that
>information from inside your procmail recipes.
>
>It's usually unnecessary though. The final destination recipient is in
>effect the envelope recipient. That information is normally stored in
>the LOGNAME environment variable.

Thanks. I'm pretty much totally ignorant about procmail. How would I
access that? Here's my context. I wanted to sort email according to
"plussed" addresses in a Sendmail setup, but, from what I read, I came to
the conclusion that I couldn't see the actual envelope address when using
procmail as a mere user. Wrong conclusion?

--
Steve Baker

re: Using plussed email addresses with sendmail and procmail [was:use sed extract username from ema

Steve Baker wrote:
> On Fri, 19 Jan 2007 20:32:03 -0700, Garen Erdoisa
> wrote:
>
>> Steve Baker wrote:
>>> On Wed, 17 Jan 2007 23:13:03 -0700, Garen Erdoisa
>>> wrote:
>>>
>>>> So, with that said, IMHO the only address you should be paying attention
>>>> to for delivery in your procmail setup is the information passed to
>>>> procmail in the ${recipient} variable given on the procmail command line
>>>> when it's invoked by postfix.
>>> I was under the impression that procmail didn't have access to the
>>> envelope information. Is that true when I invoke procmail as a user via
>>> .procmailrc in my home directory?
>>>
>> It depends on your setup. You can pass whatever information you wish to
>> procmail via command line arguments. You can then extract that
>> information from inside your procmail recipes.
>>
>> It's usually unnecessary though. The final destination recipient is in
>> effect the envelope recipient. That information is normally stored in
>> the LOGNAME environment variable.
>
> Thanks. I'm pretty much totally ignorant about procmail. How would I
> access that? Here's my context. I wanted to sort email according to
> "plussed" addresses in a Sendmail setup, but, from what I read, I came to
> the conclusion that I couldn't see the actual envelope address when using
> procmail as a mere user. Wrong conclusion?
>

The primary problem with plussed addresses is that the sender, not the
recipient gets to determine the folder name. So the recipient needs to
handle cases for specific folder names and wild card folder names.

In the case of specific folder names, you need to use some method to
detect that a specific folder name was specified by the sender, and then
tell sendmail what to do with the email in that specific case.

A simple way would be to use /etc/aliases with your plussed address
pointing to mail folder names.

ie:

Case 1)
(as root)

cd /var/mail
touch someuser+plussedfolder
chown someuser.mail someuser+plussedfolder

vi /etc/aliases

--- file: /etc/aliases ----
....

# Define where to put email sent to plussedfolder in
# someuser's account.

someuser+plussedfolder: /var/mail/someuser+plussedfolder

....
---- end of file----

newaliases

Case 2)
(as root)
cd /home/someuser/mail
touch anotherfolder
chown someuser.mail anotherfolder

vi /etc/aliases

---- file: /etc/aliases ----
....

# deliver the plussed email directly into a specific
# mail folder in the user's account
someuser+anotherfolder: /home/someuser/mail/anotherfolder

....
--- end of file ----

newaliases


Case 3)
---- File: /etc/alises ----
....

# deliver any email containing a plussed address to someuser
# to a program to handle the case.
someuser+yetanotherfolder: |somewrapperprogram

....
---- end of file ----

newaliases

In this case you'd need to design the wrapper program and read man smrsh

-=-=-=-

Case 1 or Case 2 of the above examples would properly deliver email sent
to a plussed address to a specific file folder even if the plussed
address was put in a Bcc: header by the sender.

The /etc/aliases file is what determines where to put the email if it's
other than a default delivery.

If the plussed folder name is undefined in /etc/aliases, then sendmail
will strip the +folder part and deliver the email to the someuser
account via procmail which is similar to the way Bcc: email is sent.

This last part makes it almost impossible to tell what the full plussed
envelope address was unless it's passed to procmail on the command line
which in the default sendmail configuration normally isn't the case,
though the effective envelope recipient as far as sendmail is concerned
will be placed in the LOGNAME variable, abet without the folder name.

Either of the first two cases also would not involve procmail at all,
since the /etc/alias file had the rule on where to drop the email using
the plussed address.

In the first case above, you could setup a cron job to scan plussed
folders in /var/mail to see if they contained any email, then if so, you
could use a combination of formail and procmail to forward the plussed
address email on to the primary account, and drop the email into the
correct plussed folder(s) in those accounts, or maybe add a header to
the email indicating what plussed folder was specified so the user could
use their own email client rules to determine where to drop the email.

In the 2nd case, it's a moot point, since the email in that case was
delivered directly into the user's account into a folder that they owned.

If the plussed address is given in the To: or Cc: headers, then it's
relatively simple to make a procmail rule that would drop the email into
the proper folder. This third case wouldn't involve using /etc/aliases
at all, but wouldn't take into account email sent to a plussed address
using a Bcc: header.

ie:

---- ${HOME}/.procmailrc ----

NL="
"
LOGFILE=${HOME}/procmail.log
LINEBUF=30000
MAILDIR=${HOME}/mail

# Extract the To: and Cc: headers from the email
# unfold the headers all onto one line, and replace
# any multiple tabs or spaces with single spaces.
# Note: GNU and POSIX versions of sed use a slightly different syntax.

# GNU sed
TOHEADERS=`formail -cxTo: -cxCc: |sed -e 's/[ \t]\+/ /g'`

# POSIX sed where is the actual tab character.
# TOHEADERS=`formail -cxTo: -cxCc: |sed -e 's/[ ]\{1,\}/ /g'`

....

# Look for a specific plussed address and deliver the email
# into that folder if it's found in the To: or Cc: headers
# this will not handle cases where the plussed address was
# specified by the sender in a Bcc: header.
# use /etc/aliases instead for those cases

:0
* TOHEADERS ?? someuser\+plussedfolder@example\.net
{
LOG="[$$]$_: Delivered email to ${MAILDIR}/plussedfolder${NL}"
:0:
${MAILDIR}/plussedfolder
}

:0:
${DEFAULT}
---- end of file ----

A forth case might be to pass the plussed recipient address given as the
envelope recipient on to procmail on the procmail command line then
extract it in procmail and make use of it that way.

The method I prefer just uses /etc/aliases not with plussed addresses so
much, but with random alias names that are mapped to my primary account.

plussed addresses are just another simple form of alias mapping.
I haven't found a need to get all that fancy with it.

If I were going to bother with plussed addresses I would probably use
the Case 2 example and do it that way. ie: just have sendmail drop
specific plussed address directly into a specific mail folder in the
user's account, not involving procmail at all in that case.

Note: it would be dangerous to let a sender decide what random folder
name to use in a plussed address, so any wild card cases of plussed
addresses should be dropped into a bulk incoming folder, or rejected.

You could do a plussed address rejection for random folders like this,
though it's rather a kludge. This would allow you to accept plussed
addresses to specific folders and reject otherwise.

---- File: /etc/aliases ----
....

# reject all wild card plussed addresses sent to a specific account
someuser+*: /invalidaddress

....
----end of file----

newaliases

This would have sendmail try to deliver the email to a non-existent file
name, and reject the email due to the inability to write to the
non-existent file.

--
Garen

Re: Using plussed email addresses with sendmail and procmail [was: use sed extract username from em

On Sun, 28 Jan 2007 14:40:20 -0700, Garen Erdoisa
wrote:

>> Thanks. I'm pretty much totally ignorant about procmail. How would I
>> access that? Here's my context. I wanted to sort email according to
>> "plussed" addresses in a Sendmail setup, but, from what I read, I came to
>> the conclusion that I couldn't see the actual envelope address when using
>> procmail as a mere user. Wrong conclusion?
>>
>
>The primary problem with plussed addresses is that the sender, not the
>recipient gets to determine the folder name. So the recipient needs to
>handle cases for specific folder names and wild card folder names.

Yikes! I guess the question wasn't as simple as I thought, but it seems
that my initial understanding was correct, that I couldn't do what I
wanted to do with procmail. The situation was that I was a "mere user",
and email with plussed addresses were all dropped into the one mailbox
for my account, and there was nothing reliable in the header.
I don't even have that account anymore, and I feel guilty for taking up
so much of your time. But thanks!

--
Steve Baker

Re: Using plussed email addresses with sendmail and procmail [was:use sed extract username from ema

Steve Baker wrote:
> On Sun, 28 Jan 2007 14:40:20 -0700, Garen Erdoisa
> wrote:
>
>>> Thanks. I'm pretty much totally ignorant about procmail. How would I
>>> access that? Here's my context. I wanted to sort email according to
>>> "plussed" addresses in a Sendmail setup, but, from what I read, I came to
>>> the conclusion that I couldn't see the actual envelope address when using
>>> procmail as a mere user. Wrong conclusion?
>>>
>> The primary problem with plussed addresses is that the sender, not the
>> recipient gets to determine the folder name. So the recipient needs to
>> handle cases for specific folder names and wild card folder names.
>
> Yikes! I guess the question wasn't as simple as I thought, but it seems
> that my initial understanding was correct, that I couldn't do what I
> wanted to do with procmail.

I agree that without having root on the server it's a tad harder to deal
with.

> The situation was that I was a "mere user",
> and email with plussed addresses were all dropped into the one mailbox
> for my account, and there was nothing reliable in the header.

Yes, that is the way sendmail is configured by default. However if you
ever choose to run your own email server, you can configure sendmail
differently if you so desire. Also other mail server software is out
there that may support plussed addressing by default, or could be easily
configured to support plussed addressing.

> I don't even have that account anymore, and I feel guilty for taking up
> so much of your time. But thanks!

Don't feel guilty about taking up anyone's time on USENET, it's always
their choice whether to spend the time engaging in any discussion about
an issue. They either do or they don't. :)

In cases like this one I think that it's good now and then when such
questions are raised, because the ensuing discussion can perhaps educate
some people about the issue, provide food for thought for others, and
perhaps change some opinions.

Anyway, all is not lost, so long as the sender puts the plussed address
in a To: or Cc: header you can still deal with it as a "mere user", so
long as you have shell access to the mail account so that you can setup
your own procmail recipes specific to that account, or use email client
rules that detect the presence of a plussed address and file it
accordingly. You wouldn't even need procmail for that, you could
probably do it just fine using any common email client software.

I did some tests with plussed address sent to a sendmail server a couple
of days ago, and noticed interestingly enough that the plussed folder
name given was loaded into the relay= field in the maillog for such
emails. Might be a bug. Would need to go dig up the relevant RFC to
confirm that. Normally that relay field in the sendmail log line
contains the last relay host. It didn't seem to hurt anything though.
Just made the log line look funny.

I also noticed interestingly enough that using /etc/aliases to file an
email directly to a folder or pipe it to a wrapper program had sendmail
fail to apply a Return-Path: header to the email. Apparently it just
skips some of the sendmail.cf rule sets entirely in those cases. That
means that you might lose track of any envelope From: information for
such emails. Possibly another minor bug or oversight. I hadn't messed
with those features in sendmail before.

Sendmail will leave any To: or Cc: headers intact. Bcc: mail would need
to be handled in some other way. From what I've seen personally, Bcc:
headers from legitimate bulk mail senders are not as common anymore
because so many people are now filtering email based on if their own
email address is seen in anywhere in the headers at all, and if it's
seen, whether or not a bogus real name is paired with the email address
or not. Those senders that do use Bcc: alot, usually have other header
or body patterns you can match on to have your filters decide where to
file the email.

--
Best Regards
Garen