forward problem

forward problem

am 17.05.2005 16:54:22 von David de Kloet

Hi,

Situation sketch:

User A is not a real human and its account is managed by users B, C and
D. Therefore email to A is forwarded to B, C and D. User D goes awy
and his account gets removed from the system. Now someone sends an
email to A which the mailsystem tries to forward to B, C and D. Since
D doesn't exist anymore the mailer-daemon sends a message telling that
the email to D could not be delivered. This message gets sent to A
which creates a loop.

Should this message indeed be delivered to A again and did I do
something wrong in forwarding it? Or should the error-mail not be sent
to A but somewhere else? What would be the nicest way of solving this
problem?

Any help is appreciated.

--
David

Re: forward problem

am 17.05.2005 20:42:44 von Thor Kottelin

David de Kloet wrote:

> User A is not a real human and its account is managed by users B, C and
> D. Therefore email to A is forwarded to B, C and D. User D goes awy
> and his account gets removed from the system. Now someone sends an
> email to A which the mailsystem tries to forward to B, C and D. Since
> D doesn't exist anymore the mailer-daemon sends a message telling that
> the email to D could not be delivered. This message gets sent to A
> which creates a loop.
>
> Should this message indeed be delivered to A again and did I do
> something wrong in forwarding it? Or should the error-mail not be sent
> to A but somewhere else? What would be the nicest way of solving this
> problem?

Non-delivery receipts must be marked as such (MAIL FROM: <>), and they must
never be auto-replied to.

Thor

--
http://www.anta.net/OH2GDF

Re: forward problem

am 17.05.2005 23:06:54 von David de Kloet

On Tue, 17 May 2005, Thor Kottelin wrote:

> David de Kloet wrote:
>
>> User A is not a real human and its account is managed by users B, C and
>> D. Therefore email to A is forwarded to B, C and D. User D goes awy
>> and his account gets removed from the system. Now someone sends an
>> email to A which the mailsystem tries to forward to B, C and D. Since
>> D doesn't exist anymore the mailer-daemon sends a message telling that
>> the email to D could not be delivered. This message gets sent to A
>> which creates a loop.
>>
>> Should this message indeed be delivered to A again and did I do
>> something wrong in forwarding it? Or should the error-mail not be sent
>> to A but somewhere else? What would be the nicest way of solving this
>> problem?
>
> Non-delivery receipts must be marked as such (MAIL FROM: <>), and they must
> never be auto-replied to.

Thanks for replying but I don't understand. Should I have configured
it differently? What? How?

--
David

Re: forward problem

am 18.05.2005 01:19:28 von Thor Kottelin

David de Kloet wrote:
>
> On Tue, 17 May 2005, Thor Kottelin wrote:
>
> > David de Kloet wrote:
> >
> >> User A is not a real human and its account is managed by users B, C and
> >> D. Therefore email to A is forwarded to B, C and D. User D goes awy
> >> and his account gets removed from the system. Now someone sends an
> >> email to A which the mailsystem tries to forward to B, C and D. Since
> >> D doesn't exist anymore the mailer-daemon sends a message telling that
> >> the email to D could not be delivered. This message gets sent to A
> >> which creates a loop.

> > Non-delivery receipts must be marked as such (MAIL FROM: <>), and they must
> > never be auto-replied to.
>
> Thanks for replying but I don't understand. Should I have configured
> it differently? What? How?

I don't know what you're using, or how you have configured it.

However, since your non-delivery receipt (NDR) created a loop, one or both
of the requirements I mentioned above must have been violated. A glance at
the mail server log should reveal whether the NDR carried an empty return
path, as it should have.

Thor

--
http://www.anta.net/OH2GDF

Re: forward problem

am 18.05.2005 01:51:44 von Steve Baker

On Tue, 17 May 2005 16:54:22 +0200, David de Kloet
wrote:

>User A is not a real human and its account is managed by users B, C and
>D. Therefore email to A is forwarded to B, C and D. User D goes awy
>and his account gets removed from the system. Now someone sends an
>email to A which the mailsystem tries to forward to B, C and D. Since
>D doesn't exist anymore the mailer-daemon sends a message telling that
>the email to D could not be delivered. This message gets sent to A
>which creates a loop.
>
>Should this message indeed be delivered to A again and did I do
>something wrong in forwarding it? Or should the error-mail not be sent
>to A but somewhere else?

The bounce should go to the original sender, not A. When forwarding,
say Mail From:, not Mail From:.
I'd guess that mail with an empty Return Path (Mail From:<>) probably
shouldn't be forwarded, but I'm not sure about that.

Steve Baker

Re: forward problem

am 18.05.2005 10:10:46 von David de Kloet

On Wed, 18 May 2005, Thor Kottelin wrote:

> David de Kloet wrote:
>>
>> On Tue, 17 May 2005, Thor Kottelin wrote:
>>
>>> David de Kloet wrote:
>>>
>>>> User A is not a real human and its account is managed by users B, C and
>>>> D. Therefore email to A is forwarded to B, C and D. User D goes awy
>>>> and his account gets removed from the system. Now someone sends an
>>>> email to A which the mailsystem tries to forward to B, C and D. Since
>>>> D doesn't exist anymore the mailer-daemon sends a message telling that
>>>> the email to D could not be delivered. This message gets sent to A
>>>> which creates a loop.
>
>>> Non-delivery receipts must be marked as such (MAIL FROM: <>), and they must
>>> never be auto-replied to.
>>
>> Thanks for replying but I don't understand. Should I have configured
>> it differently? What? How?
>
> I don't know what you're using, or how you have configured it.
>
> However, since your non-delivery receipt (NDR) created a loop, one or both
> of the requirements I mentioned above must have been violated. A glance at
> the mail server log should reveal whether the NDR carried an empty return
> path, as it should have.
>
> Thor

The message as it was forwarded contained the following headers
(among others):
Return-Path:
From: Postmaster FEW (automated script)
Reply-To: Postmaster FEW
To: nkp@cs.vu.nl

This is equal to the original message.

After it got into the loop it has:
Return-Path:
From:
To: nkp

So no empty fields, which one should have been empty? And should the
server have done that or should I configure procmail (or something
like it) such that it modifies the headers?

It's not my mailserver so looking at the log isn't too easy.

--
thanks,
David

Re: forward problem

am 18.05.2005 10:14:11 von David de Kloet

On Tue, 17 May 2005, Steve Baker wrote:

> On Tue, 17 May 2005 16:54:22 +0200, David de Kloet
> wrote:
>
>> User A is not a real human and its account is managed by users B, C and
>> D. Therefore email to A is forwarded to B, C and D. User D goes awy
>> and his account gets removed from the system. Now someone sends an
>> email to A which the mailsystem tries to forward to B, C and D. Since
>> D doesn't exist anymore the mailer-daemon sends a message telling that
>> the email to D could not be delivered. This message gets sent to A
>> which creates a loop.
>>
>> Should this message indeed be delivered to A again and did I do
>> something wrong in forwarding it? Or should the error-mail not be sent
>> to A but somewhere else?
>
> The bounce should go to the original sender, not A. When forwarding,
> say Mail From:, not Mail From:
.

Ok, but why does the original sender have to know that A tried to
redirect his message to a non-existing address? That's non of his
business is it?

--
David

Re: forward problem

am 20.05.2005 01:18:12 von Thor Kottelin

David de Kloet wrote:
>
> On Wed, 18 May 2005, Thor Kottelin wrote:
>
> > David de Kloet wrote:
> >>
> >> On Tue, 17 May 2005, Thor Kottelin wrote:
> >>
> >>> David de Kloet wrote:
> >>>
> >>>> User A is not a real human and its account is managed by users B, C and
> >>>> D. Therefore email to A is forwarded to B, C and D. User D goes awy
> >>>> and his account gets removed from the system. Now someone sends an
> >>>> email to A which the mailsystem tries to forward to B, C and D. Since
> >>>> D doesn't exist anymore the mailer-daemon sends a message telling that
> >>>> the email to D could not be delivered. This message gets sent to A
> >>>> which creates a loop.
> >
> >>> Non-delivery receipts must be marked as such (MAIL FROM: <>), and they must
> >>> never be auto-replied to.
> >>
> >> Thanks for replying but I don't understand. Should I have configured
> >> it differently? What? How?
> >
> > I don't know what you're using, or how you have configured it.
> >
> > However, since your non-delivery receipt (NDR) created a loop, one or both
> > of the requirements I mentioned above must have been violated. A glance at
> > the mail server log should reveal whether the NDR carried an empty return
> > path, as it should have.

> The message as it was forwarded contained the following headers
> (among others):
> Return-Path:

This would be the return path given in the SMTP dialog. The NDR should be
sent to devnull@few.vu.nl.

> This is equal to the original message.
>
> After it got into the loop it has:
> Return-Path:
> From:
> To: nkp

In order for this to occur, the sender would have said "MAIL From:
". If this is the case, and the message is a NDR, the
software sending the NDR is broken.

I'm assuming that "Return-Path: " is not the mail server's
way of saying that it actually received a "MAIL From: <>".

> So no empty fields, which one should have been empty? And should the
> server have done that or should I configure procmail (or something
> like it) such that it modifies the headers?

When sending a NDR, the server should say "MAIL From: <>". More details are
available in RFC 2821, section 3.7.

Thor

--
http://www.anta.net/OH2GDF

Re: forward problem

am 20.05.2005 10:40:08 von David de Kloet

On Fri, 20 May 2005, Thor Kottelin wrote:

> David de Kloet wrote:
>>
>> On Wed, 18 May 2005, Thor Kottelin wrote:
>>
>>> David de Kloet wrote:
>>>>
>>>> On Tue, 17 May 2005, Thor Kottelin wrote:
>>>>
>>>>> David de Kloet wrote:
>>>>>
>>>>>> User A is not a real human and its account is managed by users B, C and
>>>>>> D. Therefore email to A is forwarded to B, C and D. User D goes awy
>>>>>> and his account gets removed from the system. Now someone sends an
>>>>>> email to A which the mailsystem tries to forward to B, C and D. Since
>>>>>> D doesn't exist anymore the mailer-daemon sends a message telling that
>>>>>> the email to D could not be delivered. This message gets sent to A
>>>>>> which creates a loop.
>>>
>>>>> Non-delivery receipts must be marked as such (MAIL FROM: <>), and they must
>>>>> never be auto-replied to.
>>>>
>>>> Thanks for replying but I don't understand. Should I have configured
>>>> it differently? What? How?
>>>
>>> I don't know what you're using, or how you have configured it.
>>>
>>> However, since your non-delivery receipt (NDR) created a loop, one or both
>>> of the requirements I mentioned above must have been violated. A glance at
>>> the mail server log should reveal whether the NDR carried an empty return
>>> path, as it should have.
>
>> The message as it was forwarded contained the following headers
>> (among others):
>> Return-Path:
>
> This would be the return path given in the SMTP dialog. The NDR should be
> sent to devnull@few.vu.nl.
>
>> This is equal to the original message.
>>
>> After it got into the loop it has:
>> Return-Path:
>> From:
>> To: nkp
>
> In order for this to occur, the sender would have said "MAIL From:
> ". If this is the case, and the message is a NDR, the
> software sending the NDR is broken.
>
> I'm assuming that "Return-Path: " is not the mail server's
> way of saying that it actually received a "MAIL From: <>".
>
>> So no empty fields, which one should have been empty? And should the
>> server have done that or should I configure procmail (or something
>> like it) such that it modifies the headers?
>
> When sending a NDR, the server should say "MAIL From: <>". More details are
> available in RFC 2821, section 3.7.
>
> Thor

Thank you for explaining. I will have a look at the RFC too.

--
David