Prev: mailbox_command
Next: rate limiting by recipient domain
From: Vegard Svanberg on 22 Apr 2010 04:02
* Ansgar Wiechers <lists(a)planetcobalt.net> [2010-04-21 13:11]:

> > Example 2: user(a)example.invalid is forwarded to resu(a)example2.invalid.
> > resu(a)example2.invalid does not exist; neither as an alias nor a mailbox.
> >
> > SMTP dialog:
> >
> > rcpt to: <user(a)example.invalid>
> > 250 2.1.5 Ok
>
> This is expected behavior as well. Postfix only checks the left-hand
> side of $virtual_alias_maps. If it finds a match there, then it will
> accept the mail for further delivery.

Any ideas on how to resolve this problem (except removing the mappings)?
Alternatively, how we can gain more control over when NDRs are sent. If
all else fails, I'm thinking we might have to add body checks or add
some logic to our content filters to drop those NDRs.

> It is your job as a mail server admin to ensure that your MTA does not
> have invalid mappings.

We can do something about the second example. However, domain
forwardings (@dom1 -> @dom2) are more difficult to handle. As we
currently need them, I need to try working out a solution.

I can also see this happening in other cases, for instance when a user
has forwarded his original(a)hisdomain e-mail to
another.address(a)anotherdomain. If that address disappears somehow and a
spammer hits the original address, we have a problem. So I think we'll
have to make something with gives us more fine-grained control over
NDRs. I'll do some thinking. :)

--
Vegard Svanberg <vegard(a)svanberg.no> [*Takapa(a)IRC (EFnet)]

From: Ansgar Wiechers on 22 Apr 2010 04:58
On 2010-04-22 Vegard Svanberg wrote:
> * Ansgar Wiechers <lists(a)planetcobalt.net> [2010-04-21 13:11]:
>
>>> Example 2: user(a)example.invalid is forwarded to resu(a)example2.invalid.
>>> resu(a)example2.invalid does not exist; neither as an alias nor a mailbox.
>>>
>>> SMTP dialog:
>>>
>>> rcpt to: <user(a)example.invalid>
>>> 250 2.1.5 Ok
>>
>> This is expected behavior as well. Postfix only checks the left-hand
>> side of $virtual_alias_maps. If it finds a match there, then it will
>> accept the mail for further delivery.
>
> Any ideas on how to resolve this problem (except removing the
> mappings)? Alternatively, how we can gain more control over when NDRs
> are sent. If all else fails, I'm thinking we might have to add body
> checks or add some logic to our content filters to drop those NDRs.

No. You have to fix your mappings and that's all there is to it.

>> It is your job as a mail server admin to ensure that your MTA does
>> not have invalid mappings.
>
> We can do something about the second example. However, domain
> forwardings (@dom1 -> @dom2) are more difficult to handle. As we
> currently need them, I need to try working out a solution.

Your solution is to create appropriate mappings for existing addresses
in dom2:

user1(a)dom1 user1(a)dom2
user2(a)dom1 user2(a)dom2
....

> I can also see this happening in other cases, for instance when a user
> has forwarded his original(a)hisdomain e-mail to
> another.address(a)anotherdomain. If that address disappears somehow and
> a spammer hits the original address, we have a problem.

Yes. Dealing with this kind of problem is part of a mail admin's work.

> So I think we'll have to make something with gives us more
> fine-grained control over NDRs. I'll do some thinking. :)

Please don't. Just fix your mappings and the issue will be gone.

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

 | 
Pages: 1
Prev: mailbox_command
Next: rate limiting by recipient domain