can we do someting like "local recipient table"

[tildar]

I have noticed that most of the email I recive via rollernet result in my server saying:

Recipient address rejected: User unknown in local recipient table;

It would be great if I could suply a list user that i want to have recive mail via rolernet. IE a "local recipiant table" and have rolernet just reject the rest.

I beleave this would save space trafice and processor time for rollernet and myself.

[RollerNetSupport]

Yes, an option like that can be added. I'll start working on something to add to the filtering options.

[schraudog]

I too would greatly benefit from a local recipients table to allow rollernet to block unauth recips. ALL of the email from rollernet to my primary (when the primary is up, mind you) is to unauth'd recips. Would save you a lot
of traffic I assume, but I do not know how painful it would be for you to allow this.
A way to import this list from a file would be very helpful also. Currently I use postfix and the valid recip map looks like this:

user1@specialtyblades.com OK
user2@olfablades.com OK
user3@enduriumblades.com OK
...

[jonfry]

I'd just like to add my comments to this. The majority of spam coming into my primary server from Rollernet is to user accounts which don't exist and obviously made up by the spammers.

They are already blocked on the primary as I don't have a catch all account so it would be nice to add a list of known good receipients to Rollernet and have the rest blocked which is often the best way of telling spammers to go away if they receive errors from the MTU when trying to send.

[RollerNetSupport]

I'm in the process of finishing up a new payment processing system (one that will activate features immediately and allow us to take credit cards directly), so once that's done, a "local users" lookup will be next in line.

[RollerNetSupport]

New features announcement:

http://forums.rollernet.us/viewtopic.php?p=428

[tildar]

Thank-you.
I am realy looking forward to the rollout of this feature in November

[RollerNetSupport]

It will actually be available for use this weekend (today, if I can get all the final testing, documentation, and final coding done). From now until November, it will be optional. After that, it will be a requirement to set up the local users maps.

I will post here when it is available before the formal announcement.

[tildar]

even better news. thankyou again

[RollerNetSupport]

This feature is now available; a formal announcement will be made later this week. It is listed as "Mail Handling Options" on the main menu of the account manager.

[maxfloden]

Any chance that domains only using the Secondary MX service could be exempt from this rule? This would make at least my life a lot easier.
I can understand the need for recipient tables for SMTP redirection domains since these should amount for most of the traffic, right?

Also - I did not recieve the email letter about this supposedly sent out on Oct 16. My preference is set to "You can contact me".

[RollerNetSupport]

Any chance that domains only using the Secondary MX service could be exempt from this rule? This would make at least my life a lot easier.
I can understand the need for recipient tables for SMTP redirection domains since these should amount for most of the traffic, right?

Only about 20% of the domains in our system are in redirection mode. You'd think it would be more popular considering it's virtually unlimited use, but it isn't. Not yet, anyway.

The problem is that the directory harvest attack bots then hit us after your server rejects the messages. Our systems will accept them because we don't know any better, but your server will still reject them, causing thousands of bounces to forged addresses. This is harmless (mostly, unless the bandwidth used by a harvest attack is a concern to you) to the primary mail server since it happens before the message is queued, but it far exceeds what I consider reasonable usage especially on the free accounts. I'm not calling it abuse because I understand what's happening and why, but it's grown to such a large level that I have to do something about it.

The primary outward effects are delivery delays ranging from 1 hour to 72 hours, depending on how bad the attacks are. These delays affect everyone, regardless of delivery mode. I like to keep the processing delay less than 10 seconds.

I can't force everyone to use DNSBL or SPF, or the upcoming anti-virus or content filtering features to stem the tide - some people really don't want to use any filtering until it gets to their desktop mail program - but I can require that we only accept mail for valid destination addresses. The backscatter generated is also damaging to our reputation and has landed our mail servers on a blacklist more than once; when a primary rejects a message that we (as secondaries) accepted, then our servers generate a bounce message.

In order to ease the pain of requiring recipient maps, the API is available to insert calls into a pre-existing add/remove user system found in many larger organizations. An auto-learning version is being developed as well, but it's not yet ready. As we speak, I'm trying to fight off yet another flood of undeliverable messages on mail.rollernet.us. It's only about 500,000, but it's enough to cause delivery delays that are being noticed. It's hard for me to keep explaining to people why the service is slow, saying it will be fixed, then having it happen all over again a few days later.

Believe me, making the recipient maps a requirement was not the reason for adding them - they were a hot requested item - but I don't know what else I can do to fix the problems. I am always open to any suggestions; either post them here or send them to me personally at sethm@rollernet.us and I'll do my best to accommodate everyone's needs.

If managing the recipient maps through the account manager or an API system really is too much of a burden and you need the auto-learning version, I can make exceptions to the requirement deadline for individual domains on a case by case basis until the auto-learning system is ready.

[rushing]

In order to ease the pain of requiring recipient maps, the API is available to insert calls into a pre-existing add/remove user system found in many larger organizations.

And it doesn't even take much time to use the API semi-manually. We use rollernet as a backup MX server at a company that has just over 200 e-mail accounts. (Not all of those represent real people.)

We use Lotus Notes. I just used ldap to grab a copy of my address book. Pulled out all the lines referring to e-mail. Then converted a text file containing the e-mail addresses into a list of API urls and then fed that to WGET.

A rather crude hack and we'll need something more formal to keep it up to date, but it took me less time playing with text than it did to realize I needed to enable the API key I'd set up.

Our needs are small enough that we can manage it manually going forward, but the web API made it very easy to get up and running with recipient maps.

[maxfloden]

The reason I'm asking is actually because the around 10 domains I manage are small with only a few users in each (10-20). Problem is that some of them I co-manage and since they are so small we don't have any special process or policy for handling them which will make it easy to forget to also add new users to the recipient table. We simply add/remove/change users too rarely.

When using the SMTP forward this is not a problem because we will notice right away that the address is not working but when using it as secondary MX we might not even notice that we have forgotten to update the recipient table because it's only used when something is wrong with our mail server.

Anyway I understand your problem so I will add users to the recipient lists and put a big yellow post-it on my computer screen not to forget to update at rollernet

Could you tell me more about the learning version. Will that start out allowing everything and learn from whatever bounces, is that how it works?

Thanks.

[RollerNetSupport]

Basically, yes. It will learn from the response and cache it for a configurable period of time. For domains that are configured as a catch-all, it would only cache negative responses and assumes everything else is valid. At most, the final destination mail server would only get a single probe per email address. Most harvest attacks or dictionary attacks use the same list. Our system will still probe the destination mail server to find out if the address is valid or not, but it would only happen once before it is cached.

Many of the details are still being fine tuned, but that's the basic principle of how it works.