Re: [Exim] Fixing SPF Forward Problem by Reply-to: Hack?

On Mon, 2004-03-22 at 11:43 +0100, Giuliano Gavazzi wrote:
> At 10:18 am +0000 2004/03/22, David Woodhouse wrote:
> >On Mon, 2004-03-22 at 10:35 +0100, Giuliano Gavazzi wrote:
> >>As I've already said, this envelope sender munging is more broken than SPF.
> >
> >Envelope sender munging is required with SPF too, in the case of
> >forwarding. There's where the idea came from. So while it may indeed be
>
> not if an empty env.sender is used. As I said in another post, not
> using <> could cause secondary spam.

I'm not sure I understand... You advocate SPF but instead of fixing its
broken assumptions with SRS, you'd instead have forwarders use an empty
reverse-path in forwarded mail?

Thus denying the original sender the possibility of getting a bounce if
the mail doesn't reach its final destination?

Congratulations. You've rendered the system unreliable and thrown the
baby out with the bathwater.

> Of course you can't check if the env.sender. is valid if it's empty,
> but we are talking about the side-effects of these methods, and the
> problem here is that the other methods will reject the mail as it
> looks like a bounce to an address that is never used.

And rightly so. It's _perfectly_ acceptable to reject something which
looks like a bounce to an address which is never used in 'MAIL FROM:'

There are several types of notification messages which are sent with a
null reverse path. All of these kinds of messages are notifications
about a previous message, and they are sent to the reverse-path of the
previous mail message. All other types of messages SHOULD be sent with a
valid, non-null reverse-path.


--
dwmw2