Re: [exim] *Suspect* Re: *Suspect* reject mail for user@exam…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Régi témák: Re: [exim] *Suspect* reject mail for user@example.com?
Tárgy: Re: [exim] *Suspect* Re: *Suspect* reject mail for user@example.com?
Tomasz Chmielewski wrote:
> W B Hacker schrieb:
>
>
>> "Far-end destination addressee"?
>>
>> or combinations of
>>
>> selected remote <==> selected local/virtual
>>
>> ...is also possible, but needs DB or list matching, which may be
>> asymmetrically mapped (one:one, one:many, many:one, many:many).
>>
>> - and/or combined with other conditionals, such as 'Subject:', type of
>> attachment, time-of-day, .... MUA or OS used to compose the message ....
>>
>> No limits, really. I've got a rule somewhere that rejects anything
>> coming off a Winbox...
>>
>> Which do you seek?
>
> I have an Exim box which forwards certain addresses to another server,
> i.e.:
>
> - Exim accepts user@???
> - delivers it to server_2 for user_changed@???
>
> Now, server_2 rejects this mail for some reason (user does not exist,
> spam etc.). This means Exim will send a non-delivery report to the
> original sender. A bit too late, isn't it?
>
> This causes lots of trouble:
> - non-delivery reports get to false users (in case of rejected
> spam/viruses)


Look at the documentation and examples on:

'errors_to'

> - we send unnecessary non-delivery reports for non-existing users; it
> should be cut off as soon as someone connects to Exim
>
>
> I know the proper way to do it would be to have an up-to-date list of
> existing users on the Exim box for all "remote users", but it's not
> always possible.
>
>


You should be able to get *most* of it - if only by making a manual test
part of your initial setup as each alias is submitted.

IF THEN 'errors_to' is your valid MailAdmin address, you can nip the
rest early, contact the client for an update, and suspend that alias
until they provide a working one.

Further along this thread, there is a suggestion w/r recipient
verification callout. The promary use ofr htose iswithion/among a 'pool'
of server under common control.

IOW - that works well only when you have a cooperative far-end.

Many are not.

Some even see it as a possible zombot probe and/or abusive the call on
*their* resources, and may even BL your server.

W/R spam rejections - relaying has another downside - your server can
coem to be seen as more problematic than the many more individual source
MTA because it 'concentrates' any problems as coming off one source.

You will need to take sterner than average measures to insure YOU don't
get BL'ed, blocking all clients because of a few bad-actors.

Hope you are getting well-paid for this, 'coz it is actually more work
and risk than providing the mailstore locally.

Bill