Re: Drop the rejects from a forwarded alias

2010-11-29 Thread Will Fong

On 11/29/2010 12:28 PM, Randy Ramsdell wrote:

We simply alias

$user  $u...@$othermailserver

The $users we forward to are known by our mail server and no mail will 
forward otherwise. I cannot think of a scenario which rejected mail 
from $othermailserver would be anything other than UCE in this case. 
The fringe issues would be a borked config which reject because of 
misconfiguration on their end which would result is lost mail if we 
drop all rejects from $othermailserver.



Hi Randy,

Just wondering, why do you need two servers in the first place? Why not 
just set the MX to $othermailserver? Or, have $othermailserver forward 
to your server? Just trying to think of some alternatives...


HTH,
-will





Re: Drop the rejects from a forwarded alias

2010-11-29 Thread lst_hoe02

Zitat von Randy Ramsdell :


Victor Duchovni wrote:

On Mon, Nov 29, 2010 at 03:01:45PM -0500, Randy Ramsdell wrote:

So to rephrase, what would be the best practices way given I have  
to do forward this email and am powerless to change the design  
other than our setup which may only include trying to mitigate  
backskatter?


If list expansion happens on your server, you can implement standard
list management methods (an envelope sender address that is a list
bounce-parser that uses VERP).

If you are simply forwarding mail to an already expanded list, there
is not much you can do. The list management problem is upstream, and
needs to be handled there.



We simply alias

$user  $u...@$othermailserver

The $users we forward to are known by our mail server and no mail  
will forward otherwise. I cannot think of a scenario which rejected  
mail from $othermailserver would be anything other than UCE in this  
case. The fringe issues would be a borked config which reject  
because of misconfiguration on their end which would result is lost  
mail if we drop all rejects from $othermailserver.


What scenarios could occur which would make dropping these rejects a  
bad idea?


UCE or not will dedecided by the *remote* Exchange and if it fails  
(reject non spam) you are responsible in the first place because the  
mail was *directed* to your server. Therefore be prepared to proof the  
rejects so you don't get blamed for others faults.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Drop the rejects from a forwarded alias

2010-11-29 Thread Wietse Venema
Randy Ramsdell:
> We simply alias
> 
> $user  $u...@$othermailserver
> 
> The $users we forward to are known by our mail server and no mail will 
> forward otherwise. I cannot think of a scenario which rejected mail from 
> $othermailserver would be anything other than UCE in this case. The 
> fringe issues would be a borked config which reject because of 
> misconfiguration on their end which would result is lost mail if we drop 
> all rejects from $othermailserver.
> 
> What scenarios could occur which would make dropping these rejects a bad 
> idea?

Spamfilters are imperfect and will have false rejects (either that,
or they would pass all spam).

This means you would be dropping legitimate mail into the bit bucket.

A better approach is that the down-stream system not reject mail,
instead provide a quarantine service.

Wietse


Re: Drop the rejects from a forwarded alias

2010-11-29 Thread lst_hoe02

Zitat von Randy Ramsdell :


lst_ho...@kwsoft.de wrote:

Zitat von Randy Ramsdell :


Hi,

I am going to have to implement something that drops rejected mail  
from one of our aliases.


The scenario is that we forward to a external server and cannot  
match its spam/UCE rules so our server backskatters mail.


One way would be to drop all rejects. I think this will work  
because our server handles the $users and only forwards known.


Or what would be the best practices way?



Best practice is to not forward mail to destinations which don't  
accept it. If the detination has no feature of "whitelist" your  
server, disable forwarding to that destination. All other options  
lead to potential mail blackholes which are worse than spam.


Regards

Andreas





I understand this. However, I cannot tell the President of our  
company that he can't use his exchange server and it is beyond my  
control to change the hosted exchange server configuration. I have  
to forward this mail no matter what I think should be done.


So to rephrase, what would be the best practices way given I have to  
do forward this email and am powerless to change the design other  
than our setup which may only include trying to mitigate backskatter?


Be prepared that your President will loose mail some time in the  
future. Try to tighten Spam rules as much as possible for accounts in  
question.
a.) redirect bounces to some archive mailbox to prove that it was not  
your fault

or
b.) let bounces go its way and hope there are few enough so no one notices

It's your choice but nothing of these can be called best practice.

Regards

Andreas






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Drop the rejects from a forwarded alias

2010-11-29 Thread Randy Ramsdell

Victor Duchovni wrote:

On Mon, Nov 29, 2010 at 03:01:45PM -0500, Randy Ramsdell wrote:

So to rephrase, what would be the best practices way given I have to do 
forward this email and am powerless to change the design other than our 
setup which may only include trying to mitigate backskatter?


If list expansion happens on your server, you can implement standard
list management methods (an envelope sender address that is a list
bounce-parser that uses VERP).

>

If you are simply forwarding mail to an already expanded list, there
is not much you can do. The list management problem is upstream, and
needs to be handled there.



We simply alias

$user  $u...@$othermailserver

The $users we forward to are known by our mail server and no mail will 
forward otherwise. I cannot think of a scenario which rejected mail from 
$othermailserver would be anything other than UCE in this case. The 
fringe issues would be a borked config which reject because of 
misconfiguration on their end which would result is lost mail if we drop 
all rejects from $othermailserver.


What scenarios could occur which would make dropping these rejects a bad 
idea?




Re: Drop the rejects from a forwarded alias

2010-11-29 Thread Ansgar Wiechers
On 2010-11-29 Randy Ramsdell wrote:
> lst_ho...@kwsoft.de wrote:
>> Zitat von Randy Ramsdell :
>>> I am going to have to implement something that drops rejected mail
>>> from one of our aliases.
>>>
>>> The scenario is that we forward to a external server and cannot
>>> match  its spam/UCE rules so our server backskatters mail.
>>>
>>> One way would be to drop all rejects. I think this will work because
>>> our server handles the $users and only forwards known.
>>>
>>> Or what would be the best practices way?
>>
>> Best practice is to not forward mail to destinations which don't
>> accept  it. If the detination has no feature of "whitelist" your
>> server, disable forwarding to that destination. All other options
>> lead to potential mail blackholes which are worse than spam.
>
> I understand this. However, I cannot tell the President of our company
> that he can't use his exchange server and it is beyond my control to
> change the hosted exchange server configuration. I have to forward
> this  mail no matter what I think should be done.

Have you tried talking to the president of your company and/or the
people who can change the hosted exchange server configuration?

> So to rephrase, what would be the best practices way given I have to
> do  forward this email and am powerless to change the design other
> than our  setup which may only include trying to mitigate backskatter?

Then you cannot avoid being a backscatter source or a mail blackhole or
both. Plain and simple.

Regards
Ansgar Wiechers
-- 
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky


Re: Drop the rejects from a forwarded alias

2010-11-29 Thread Victor Duchovni
On Mon, Nov 29, 2010 at 03:01:45PM -0500, Randy Ramsdell wrote:

> So to rephrase, what would be the best practices way given I have to do 
> forward this email and am powerless to change the design other than our 
> setup which may only include trying to mitigate backskatter?

If list expansion happens on your server, you can implement standard
list management methods (an envelope sender address that is a list
bounce-parser that uses VERP).

If you are simply forwarding mail to an already expanded list, there
is not much you can do. The list management problem is upstream, and
needs to be handled there.

-- 
Viktor.


Re: Drop the rejects from a forwarded alias

2010-11-29 Thread Randy Ramsdell

lst_ho...@kwsoft.de wrote:

Zitat von Randy Ramsdell :


Hi,

I am going to have to implement something that drops rejected mail 
from one of our aliases.


The scenario is that we forward to a external server and cannot match 
its spam/UCE rules so our server backskatters mail.


One way would be to drop all rejects. I think this will work because 
our server handles the $users and only forwards known.


Or what would be the best practices way?



Best practice is to not forward mail to destinations which don't accept 
it. If the detination has no feature of "whitelist" your server, disable 
forwarding to that destination. All other options lead to potential mail 
blackholes which are worse than spam.


Regards

Andreas





I understand this. However, I cannot tell the President of our company 
that he can't use his exchange server and it is beyond my control to 
change the hosted exchange server configuration. I have to forward this 
mail no matter what I think should be done.


So to rephrase, what would be the best practices way given I have to do 
forward this email and am powerless to change the design other than our 
setup which may only include trying to mitigate backskatter?


Re: Drop the rejects from a forwarded alias

2010-11-29 Thread Wietse Venema
Randy Ramsdell :
> I am going to have to implement something that drops rejected mail  
> from one of our aliases.
>
> The scenario is that we forward to a external server and cannot  
> match its spam/UCE rules so our server backskatters mail.

If this alias is a mail distribution list, then it should be
configured to override the envelope sender address, so that bounces
aren't returned to the original sender, but to the maintainer of
the mail distribution list.

/etc/aliases:
listname: 
owner-listname: u...@example.com

See "man 5 aliases" and look for "owner".

Wietse


Re: Drop the rejects from a forwarded alias

2010-11-29 Thread lst_hoe02

Zitat von Randy Ramsdell :


Hi,

I am going to have to implement something that drops rejected mail  
from one of our aliases.


The scenario is that we forward to a external server and cannot  
match its spam/UCE rules so our server backskatters mail.


One way would be to drop all rejects. I think this will work because  
our server handles the $users and only forwards known.


Or what would be the best practices way?



Best practice is to not forward mail to destinations which don't  
accept it. If the detination has no feature of "whitelist" your  
server, disable forwarding to that destination. All other options lead  
to potential mail blackholes which are worse than spam.


Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature


Drop the rejects from a forwarded alias

2010-11-29 Thread Randy Ramsdell

Hi,

I am going to have to implement something that drops rejected mail from 
one of our aliases.


The scenario is that we forward to a external server and cannot match 
its spam/UCE rules so our server backskatters mail.


One way would be to drop all rejects. I think this will work because our 
server handles the $users and only forwards known.


Or what would be the best practices way?

Thanks,
RCR