Subject: Re: [Asrg] Default SPF Enablement?

From: "Jon Kyme" <[email-masked]>
Date: Wed, 01 Feb 2006 10:19:34 +0000

Claus Assmann wrote:
> 
> What will happen if the mail can't be delivered (after forwarding)?
> Do you want the bounce to end up on the forwarding system? Someone
> has to inform the "original" sender, right?
> 

So, we inform the "original sender" that the *forwarded to* address (which
they may never have heard of) is broken? How useful is this?

> PS: we are talking about forwarding (at the MTA level), not resending
> (at the MUA level).
> 
Often, forwarding is accomplished via a third class of agent (Mail Delivery
Agent (MDA)) . It's arguable that forwarding is a function of the MDA
logically - A local delivery to a software agent (rather than to a mailbox)
has taken place and a *new* message consequently enters the MTS.

Of course, the particular issue with forwarding messages with the null
sender has to be addressed. But that's not a general objection.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 1 Feb 2006 13:33:41 -0500 (EST)

> they may never have heard of) is broken? How useful is this?

When I can read the headers to determine who forwarded it (so I know
who I sent it to), that's quite useful.

Consider a VERP'd mailing list.

Seth

---

From: John Levine <[email-masked]>
Date: 2 Feb 2006 03:10:52 -0000

>who I sent it to), that's quite useful.

When it's a bounce of an actual no kidding message and I can look at
what's quoted in the bounce to see what I wrote, extremely useful.

Sometimes I get the impression that people who attempt to design mail
systems don't actually use them.

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Feb 2006 06:27:57 +0100

Jon Kyme wrote:

> So, we inform the "original sender" that the *forwarded to*
> address (which they may never have heard of) is broken? How
> useful is this?

Depends.  So far I got one "551 emulation" bounce in 21 months
caused by the SPF FAIL:  The original receiver was some kind of
"whoisguard" encrypted Tech-C address forwarded to a 3rd party
checking SPF.

This 3rd party rejected the FAIL, therefore the forwarder sent
a bounce to me with the complete error message it got, that
included the address of the final receiver, so I could simply
send my message again to the final address.

Working as designed for "5.3.6(a) forwarders" not interested
in SPF FAIL issues.

OTOH if one of the next hops has serious problems like "no such
user" this would be very interesting for the forwarder:  If it
forwards arbitrary mails to a destination that never works it's
net abuse, today most mails are spam with a bogus MAIL FROM.

1123 5.3.6(a) forwarding cannot work when most mails are spam:
If any hop behind the forwarder rejects the mail the bounces
hit innocent bystanders.

Unless it was an SPF PASS, auto-responses (NDNs or challenges)
to a Return-Path with SPF PASS cannot hit innocent bystanders.

Quite simple, no chance to get it wrong as long as SPF checking
systems _reject_ FAIL.  If they _drop_ FAIL they're in trouble.

> It's arguable that forwarding is a function of the MDA
> logically - A local delivery to a software agent (rather than
> to a mailbox) has taken place and a *new* message
> consequently enters the MTS.

If all new recipients are within the same organization (no MX
of a 3rd party involved) keeping the MAIL FROM as is should be
okay.  But even if it's modified, and the mail is forwarded to
addresses at 3rd parties it's still the same *old* message and
the same *old* Message-ID.

For a really *new* message you'd also need a *new* Message-ID
or at least a Resent-Message-ID.  One of the many issues with
PRA aka SenderID, here violating a 2822-SHOULD without saying
so - I'm too lazy to check this, a formal but no real problem.

> Of course, the particular issue with forwarding messages with
> the null sender has to be addressed. But that's not a general
> objection.

MAIL FROM:<> can't cause bounces to innocent bystanders.  If it
attracts backscatter to (2)822-addresses the auto-responder is
broken (from a 3834 POV).
                         Bye, Frank