Re: [exim] Discard bounce notification emails before they ar…

luda posch wrote:
>>
>> 1. What are the emails? What is content?
>>
>
> The emails are usually fliers for upcoming events that my company is hosting
>
>
>>
>> 2. You control servers which send emails to your relay.
>> Why those servers send emails to nonexistent addresses
>> and with nonexistent $sender_address?
>>
>>
> I have a few web servers which act as front-end interfaces to
> manage/maintain/deploy emails. Nonexistent recipients arrise for a number
> of reasons, number one being that some of our users did not supply their
> real email address. Number two is probably that some of our email addresses
> were submitted years ago and may not be valid any longer. Nonexistent
> sender addresses occur because the web server interface (third party
> software we did not develop) is seriously flawed and unfortunately upper
> management has determined that they have made too big of an investment in it
> to ditch at this point (other wise I would suggest eliminating it
> immediately)
>
> We only accept relays from our servers, all other emails are rejected. We
> are logging bounces as they occur to a database and removing problematic
> email addresses so that we do not send to them again. We are not
> "spammers", our bulk email is solicited.
>
> These are the reasons why we do not want to send a bounce notification email
> ever. First, because it wastes resources that we do not need to be wasting
> because of our bounce tracking system in place, second, because the web
> interface that generates the emails is very poorly designed and results in
> our attempt to deliver a bounce notification to bounce, which wastes more
> resources, third, because since no "human" should be using this machine a
> bounce notification would not even be useful.
>
> Thank you

Even if the various 'web interface' front-ends were perfect, the best way
forward would still be to:

- interpose a competent Mailing List Manager engine

- configure the MLM to *start* with a double-opt-in note to each newly
submitted/harvested address. Make it a pleasant and friendly note thanking them
for stopping in and indicating an interest in ... it need not be rude or
mechanical, but should be *short* AND NOT polluted with html or graphics that
might trip a spam filter.

+ At this point you have a mechanism to insure a clean starting point and
creation of lists of only those who genuinely DO want coverage.

At that moment, anyway. Minds will change. Folks will change jobs.

Thereafter, the MLM can take care of unsubscribe requests and auto-unsubscribe
on persistent bounce for you. Setting it closed-post with replies only to a
second, short list of support, sales, engineering, R&D, <internal whomever> AND
NOT other list members, can utilize other MLM features to make responding to
clients easier as well.

Can one configure Exim to do this without an MLM?

Certainly.

But once past the simpler parts, you will have to reinvent, in the dark, though
not entirely alone, what MLM devels have already accomplished many times over.

A waste of time, given many good MLM are F/OSS, install from pkg in a New York
Minute, and have active devel & support communities of their own with
experience at covering all manner of needs..

Given, for example, 'Mailman' as an MLM choice, Exim will then need only modest
config tweaks to play well with it - all of which are on roads well traveled.

And you should then have not only a 'don't care' capability w/r flaws in the web
interface, but an intermediary in the MLM that could eventually permit shedding
some or all of them.

JM2CW, and YMMV, but this sort of need is not at all new....

Bill