Possible to make/implement "wildcard" forwards, i.e. userA.*@domain.com?

G

gof

Verified User
Joined
Oct 21, 2003
Messages
17
With spam and worse, backscatter, using a catchall is becoming problematic. As an option, it would be nice to create a sort of wildcard feature in the DA control panel as part of the forwarding system. It would work something like

userA* -> [email protected]
userB* -> [email protected]
[email protected] goes to userA
userA.amazon@domain goes to userA
userB.throwaway@domain goes to userB
etc.

Then if one of the "sub" addresses starts getting spammed it gets dropped (this is what I use the catchall for). It's too much of a PITA to make all these subs as regular forwards, often you make them up on the fly. But then you could have subs for more than one user as well.

If this were implemented, more people could probably get rid of catchall completely. You could program in a few generic wildcards to catch common misspellings of email addresses (especially where they are names).

Is this possible from the DA panel as a user/reseller? Or is it possible to implement?
 
Last edited:
Gof,

Your question is exactly my question.
Sorry to say I have no answer either, but if you find anything to this, please post it here. I'll do the same.

Thanks,

Jorge.
 
I haven't found anything in exim that would implement this. If you have let me know and I'll look into including in in exim.conf. Once it's in exim.conf it'd be easy enough to create a plugin to make it work in DA.

Jeff
 
I'm not sure, but could this lead to something that would allow the suggested 'wildcard' forwards? I found it in the exim documentation (or I thought it was the documentation anyway) and looks to be doing something in these directions.

I know it's kind of the opposite of what I would like, but could some reverse of this be a solution? I haven't looked into it yet, I am not that familiar with the exim.conf file statements. I'll be playing with this to see if it can do what I want it to, unless someone can tell me this can't work, period ..?




46.8 Multiple user mailboxes

Heavy email users often want to operate with multiple mailboxes, into which incoming mail is automatically sorted. A popular way of handling this is to allow users to use multiple sender addresses, so that replies can easily be identified. Users are permitted to add prefixes or suffixes to their local parts for this purpose. The wildcard facility of the generic router options local_part_prefix and local_part_suffix can be used for this. For example, consider this router:

userforward:
driver = redirect
check_local_user
file = $home/.forward
local_part_suffix = -*
local_part_suffix_optional
allow_filter

It runs a user’s .forward file for all local parts of the form username-*. Within the filter file the user can distinguish different cases by testing the variable $local_part_suffix. For example:

if $local_part_suffix contains -special then
save /home/$local_part/Mail/special
endif

If the filter file does not exist, or does not deal with such addresses, they fall through to subsequent routers, and, assuming no subsequent use of the local_part_suffix option is made, they presumably fail. Thus, users have control over which suffixes are valid.

Alternatively, a suffix can be used to trigger the use of a different .forward file – which is the way a similar facility is implemented in another MTA:

userforward:
driver = redirect
check_local_user
file = $home/.forward$local_part_suffix
local_part_suffix = -*
local_part_suffix_optional
allow_filter

If there is no suffix, .forward is used; if the suffix is -special, for example, .forward-special is used. Once again, if the appropriate file does not exist, or does not deal with the address, it is passed on to subsequent routers, which could, if required, look for an unqualified .forward file to use as a default.
 
I finally found a way to implement this in exim.

What I did is actually quite simple:

In exim.conf I have added a new director, almost the same as the domain_filter director, and right below it, just using a different filter file:

user_filter:
driver = redirect
allow_filter
no_check_local_user
condition = "${if exists{/etc/virtual/${domain}/userfilter}{yes}{no}}"
user = "mail"
file = /etc/virtual/${domain}/userfilter
file_transport = address_file
pipe_transport = virtual_address_pipe
retry_use_local_part
no_verify


Next I created a file called userfilter (with the same rights as the other files in the same dir) in my /etc/virtual/<domainname> directory:

# Exim Filter
# created by me
if error_message then finish endif
if
$header_to: begins "jw."
then
deliver [email protected]
endif
if
$header_cc: begins "jw."
then
deliver [email protected]
endif


That's all.

Now if an email is send to jw.whatever@<domainname> it will be delivered at [email protected].

There are a number of conditions to filter on.
These have been taken from this document:
http://www.exim.org/exim-html-current/doc/html/filter.html#SEC23

I have tested it, and it works for me, but I would love to have some easier interface in directadmin to manipulate the userfilter file.


Hope this helps for you also, good luck..!

Jorge.
 
jvdwilk said:
I have tested it, and it works for me, but I would love to have some easier interface in directadmin to manipulate the userfilter file.
Click to expand...
It works because you haven't tested it with a Bcc email.

Fix it so it works for Bcc as well (hint, there is NO Bcc header), and I'll put it into SpamBlocker exim.conf and talk to John and Mark about possibly at some point implementing an interface into DA, or perhaps someone will write a plugin.

Jeff
 
Great!

Wow, I'm glad I checked back on this. What are the chances this will make it into an update for DA in the near future?

Where I'm at the number of dictionary spam attacks has apparently started them to disable the catch-all option for many (I've still got it, but I can see how it can be an issue). With this as a forwarding type option, I'd be able to handle disabling catch-all. As long as people don't do something silly like make the header_to string a single letter (or all letters and numbers) then it should work fine.
 
I still don't see how to resolve the BCC issue. If someone writes a complete spec, I'll look at implementing it in exim.conf.

Jeff
 
I'm ignorant of Exim other than familiarity with such filtering scripts/languages. A little google searching turned up this which might be a lead to getting a handle on the Bcc field.

http://http://www.mirrorservice.org/sites/ftp.csx.cam.ac.uk/pub/software/email/exim/ChangeLogs/ChangeLog-4.42

Specifically, I'm looking at this section
5. Some internal re-factoring in preparation for the addition of Sieve
extensions (by MH). In particular, the "personal" test is moved to a
separate function, and given an option for scanning Cc: and Bcc: (which is
not set for Exim filters).
Click to expand...

Perhaps a variable might get set in the "personal" test section to allow subsequent testing by the filters? Note this is for the changelog in 4.42. I have no idea what the current version actually is on DA...
 
Hmmm.... There's no way to scan Bcc on incoming email because it doesn't exist.

I suppose this can be done by looking at the Envelope-to field, if it's available in filters. Can you check that?

Jeff
 
Bumping to see if anyone came up with an idea how to implement this.
 
Let's start again.

The Bcc field doesn't exist. The first mailserver that gets the email removes it.

So how can you filter on it?

You can't.

When exim receives an email it adds an Envelope-to field.

If that field is available in exim filters (as manamged by /etc/exim.pl) then you can filter on that. I have no idea if you can filter on that or not; feel free to create your own test and let us know if it works.

Don't forget to maintain the current exim.pl structure; simply add another filter.

Jeff
 
jlasman said:
Let's start again.

The Bcc field doesn't exist. The first mailserver that gets the email removes it.

So how can you filter on it?
Click to expand...

May be it shouldn't be implemented via filters but rather with routers using local_part_prefix/local_part_suffix.

Here is what I have so far:
Code: 
verp_director:
  driver = redirect
  allow_defer
  allow_fail
  data = newsletter@${domain}
  file_transport = address_file
  pipe_transport = address_pipe
#  retry_use_local_part
  local_part_prefix = newsletter-

This is intended to forward [email protected] to [email protected], but so far it only works for mails sent via SSH.
If I send e-mail to [email protected] from gmail, it gets bounced with "Unknown user" error.
 
Webcart said:
but so far it only works for mails sent via SSH.
If I send e-mail to [email protected] from gmail, it gets bounced with "Unknown user" error.
Click to expand...
Of course; unless the username is implemented in DirectAdmin, or plus-addressing is implemented, it won't work for external users; they're trying to verify the address.

Can plus-addressing be implemented? Perhaps; here (latenightpc.com) is some code to look at.

Implementing this is an important part of the puzzle; needed for any implementation. I don't know if that code at the top is all it takes or not; I haven't tried it.

Note I've been waiting over four years for someone to check out something for me; see post #13 above.

I'll be working on exim.conf again shortly; let's see if anyone comes up with anything. Note that when I start working on the next version of the file I'm going to open a thread asking for feature requests; only requests in that thread will be considered.

Jeff
 
You must log in or register to reply here.
Back
Top