Re: [exim] noreplys...

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: W B Hacker
Ημερομηνία:  
Προς: exim users
Αντικείμενο: Re: [exim] noreplys...
John Doe wrote:
> ----- Original Message ----
>
>> From: W B Hacker <wbh@???>
>> To: exim-users@???
>> Sent: Saturday, October 18, 2008 4:57:43 AM
>> Subject: Re: [exim] noreplys...
>>
>> Oliver von Bueren wrote:
>>
>>> A clean way without any risk is probably not possible. If you have a
>>> list of members and only inform them if they send a message to the
>>> noreply@ address, this reduces the risk quite a lot. But then why would
>>> you want to do that if you can limit the senders which can send you mail
>>> to that email address then anyway? It only annoys to do it through a web
>>> page and not just use regular email to get in contact with a company one
>>> does business with anyway.
>>>
>> A 'reasonably clean' way - presuming one is already running a Mailing
>> List Manager, is to establish a specialized internal list with at least
>> your 'responsible party' as a member, and at most, a team of several
>> folks, such as sales or helpdesk staff.
>>
>> IF the 'main' list(s) are set closed, optionally 'no post' (outbound
>> only), AND the messages show the 'internal' list address as the from and
>> reply-to, AND the internal list allows members of the main list(s) to
>> post to it...
>>
>> THEN you'll have a valid address to the smtp world, YET handle any
>> restrictions (such as 'must be a member of ..' within your MLM, rahter
>> than askign Exim to make the choices.
>>
>> Not a great deal more work can insure that a closed-post list is not
>> abused for backscatter bouncing of spam.
>>
>> As always, there should also be a working postmaster@ for each domain,
>> but the above trick will at least separate membership traffic into a
>> separately managed category, making it easier to keep the member on-side.
>>
>>> To implement such a solution, you'd probably have to build some ACL for
>>> the RCPT part to only accept messages to that address from a list of
>>> given sender addresses and then implement the autoreply. For some
>>> examples of autoreply check out this faq wiki entry:
>>> http://wiki.exim.org/EximAutoReply
>>>
>>> For the ACL in the acl_smtp_rcpt part you could start with something
>>> like this... (not tested!)
>>>
>>>    deny    message      = This address can only be used by registered 
>>> members.
>>>            recipients   = noreply@???
>>>            senders      = ! /list/to/addresses

>>>
>>> This causes a message sent to noreply@??? not coming from an
>>> address listed in the file (one address per line) to be rejected with
>>> the given reason.
>>>
>> .. essentially duplicating what the MLM (as above) can do, and arguably
>> earlier in the process and more efficiently.
>>
>> HOWEVER - any MLM still has a lage set of other handling options, many
>> of them menu/box-tick configurable. Chief among these is simply the
>> management of subscribe+confirm and unsubscribe properly, auto-pruning
>> members who cannot be reached after 'n' attempts over 't' time, etc.
>>
>> Well-known behaviour patterns, ease of admin, and active admin/developer
>> groups are good reasons to use an MLM rather than reinvent one within Exim.
>>
>> YMMV,
>>
>> Bill Hacker
>>
>>> This is not fool prof either, as the sender address can always be forged.
>>>
>>> Oliver
>


Doing so successfully is a non-trivial exercise if Exim's other 'eyes'
are open.

> Thanks to both of you.
> I wonder if it would be possible to sign a part of the email in order to verify that the reply is an authentic one...
> We will have to spend some time on the subject I guess...
>
> Thx again,
> JD
>


Ecartis, to name only the one I use, can do, and automagically DOES do
for admin traffic. Hashed cookies with configurable expiration lives,
even. Not hard to bend that feature to your will.

Though Ecartis was desinged apurpose for secure admin entirely by email,
*usually* anything one mainstream app can do its competition can also do.

So if, for example, Mailman is your pref, then dig into its docs and/or
search its support list archives.

Very seldom is there a challenge someone else has not already found an
answer for. Or several answers.

Bill