Re: [secdir] Review of draft-freed-sieve-notary-07

[Tero Kivinen <[e-mail]>]

Alexey Melnikov writes:
> The answer to your question is "it depends on an implementation". The 
> redirect action is defined in section 4.2 of RFC 5228, which says:
> 
>    The envelope sender address on the outgoing message is chosen by the
>    sieve implementation.  It MAY be copied from the message being
>    processed.  However, if the message being processed has an empty
>    envelope sender address the outgoing message MUST also have an empty
>    envelope sender address.  This last requirement is imposed to prevent
>    loops in the case where a message is redirected to an invalid address
>    when then returns a delivery status notification that also ends up
>    being redirected to the same invalid address.

Ok. Then it might be good idea to mention this also in this document,
as it affects where the status notifications are going to, i.e. if
user decides he wants to request status notifications, he does not
know whether it goes to the original author or to his own address.

> >The number of delivery status notifications can be quite large,
> >especially if the ":bytrace" option of the redirect is used, as then
> >every single future step for email processing, will send "relayed"
> >status notification, and if there is for example mail loop or similar,
> >this can be several dozen of status notifications.
> >
> Can you clarify what do you mean by "every single future step for email 
> processing"?
> 
> My recollection is that for any given SMTP path from a sender to a 
> recipient only a single "relay" DSN can be generated.

No. If I send email from my home machine to [e-mail] address,
and use the trace option of DELIVERYBY feature I will get one status
notification when my local machine takes email in and relays it to
iki.fi mail server. Then I get another status notification when the
iki.fi email-server gets message in and forwards it to iki.fi-spam
filter (this setting is per user setting and the spam processing is
done on the other machine). Then I get next one when the spam filter
machine is done running the spamassasin and forwards that email to my
real end delivery address (which in my case happens to be my home
machine kivinen.iki.fi). Then when my home machine gets the email
again now with envelope receiver of [e-mail] (as
rewritten by the iki.fi machines) it will send me the fourth trace
message.

So every single machine which relays the email sends the status
notification saying the email was relayed.

Now when I noticed there is such feature, I have found it quite useful
when debugging email problems.

I am one of the maintainers of the iki.fi, which provides permanent
email forwarding services, and quite often our members complain that
their emails does not get through, and now I have easy way of sending
one email with trace option and I can see from DSNs that the email
goes through iki.fi machines without delays and problems, and that the
email was delivered to the members next step machine (which usually
does not enable DELIVERYBY so I do not get any further reports).

So if someone enables trace option in the middle and then redirects
the email to forward then there might be several of those relayed
status notifications sent to either to the original author or to the
one running the sieve (depending which envelope sender the sieve
implementation used).

> >This should most likely be mentioned in the security considerations
> >section more clearly. The security considerations section do warn
> >about generating status notification, and says that
> >
> >  "Sites which limit the ability to request success notifications will
> >   also need to restrict the ability to request them using the
> >   redirect-dsn extension."
> >
> >but that does not help at all, as if the original senders site limits
> >the ability to request notifications, the host running sieve email
> >filter of the receiver might not have such restrictions, thus receiver
> >can enable them even when they were forbidden from the sender.

Ok, now this also makes bit more sense, as if the sieve implmentation
decides to rewrite the envelope sender then this restriction is
appropriate, but if it does not rewrite the envelope sender, then it
does not help, as the machine running sieve might not know the policy
required by the original senders machine, i.e. whether the original
sender was allowed to request those status notifications or not.
-- 
[e-mail]