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
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
