On Thu, Jun 23, 2005 at 05:29:54PM -0400, Dick St.Peters wrote:
Using my earlier example, mail would arrive here as mail
JaneDoe(_at_)aol(_dot_)com --> JohnBuck(_at_)example(_dot_)com
and leave as mail
JaneDoe(_at_)aol(_dot_)com --> JohnBuck(_at_)BigIsp(_dot_)com
Among other things, forwarding means DSNs go to the right place, in
this example to JaneDoe(_at_)aol(_dot_)com(_dot_)
Not at all. JaneDoe(_at_)aol(_dot_)com doesn't want that DSN. That's the sole
purpose of SPF. BigIsp.com should not send a DSN as the message was
NOT SENT BY AOL.
See the difference? It MAY have _originated_ at aol but BigIsp.com
cannot be sure. Not unless prior agreements exist between example.com
and BigIsp.com, in which case BigIsp.com should not use SPF at all on
the message. Example.com is just another border-MTA in that case.
The days of reporting errors after accepting the message have gone,
quite a few years now. It just doesn't work anymore.
It is the responsibility of JohnBuck to handle this situation. Yes,
he can hire help (a provider) to do this job.
The message was sent by JohnBuck(_at_)example(_dot_)com and that's where the
DSN needs to go. You will probably be thinking of looping messages
right now. Jane cannot help that. example.com and/or bigisp.com
need to fix that.
JohnBuck(_at_)example(_dot_)com or his postmaster or his provider, or a similar
entity at the BigIsp.com side, has a problem. Jane cannot fix that.
She doesn't need to care, after all "someserver.example.com" accepted
the message and acknowledged the handover of responsibility by issuing
a 2xx message after the single dot. If she want's a delivery confirmation,
see can ask for a delivery receipt. Yes, I know this can be denied at
the other end. So can DSNs.
Chances are JohnBuck doesn't want JaneDoe to know about BigIsp.com,
sending a DSN would be a mistake in that case. In other cases, it
is just confusing. JaneDoe never sent a message to BigIsp.com and
may not even be able to link that address with the one she sent to.
This, plus that it may be burried inbetween all of those other DSNs,
resulting from spam, viruses and other malicious stuff.
this example to JaneDoe(_at_)aol(_dot_)com(_dot_) Forwarding with the
envelope intact
is (or at least has been) considered a premium service compared to
resending, somewhat like direct connection vs. proxying.
1. SPF does not break resending a message.
2. SPF does not break relaying, ...
True enough, but SPF does break forwarding. Forwarders have to become
resenders.
Forwarding as discussed is a user level process. A message is received,
by a user (by means of automation, yes), the message is altered, the
message is resent. It is a new message, very close but not equal to
the original. Therefore, the message deserves a new "From:" and a new
"MAILFROM". Yes, this means you need to be carefull not to loop error
messages between example.com and bigisp.com, but this is a local problem,
it has nothing to do with janedoe(_at_)aol(_dot_)com(_dot_)
Forwarders as discussed here _are_ resenders. Well, take the original
message, put it into a new envelope and resend. Unwrap at the new
location et presto, problem solved. Add some error handling to cover
for mistakes at example.com or bigisp.com as required.
This causes problems of its own. For example, some of my users have
opted out of my anti-spam filtering, so at their request I resend tons
of spam to them. The providers they have me forward ... er, resend to
see all this junk coming from my domain.
So what are you proposing? You have a problem handling the mess your
user creates, so you want bounces go to me or other forged addresses
in stead of you, is that it? You mean you want the money from your
user and _i_ should clean up _your_ mess?
There's a commercial anti-spam package that has an option to regard
all mail with "=" character in the MAILFROM as spam. SRS rewriting
uses "=" as a separator, so sites running this anti-spam package
reject all SRS-rewritten mail if they've enabled the option.
So, you've found a commercial package with a serious bug. What if you
find a package that considers all MAILFROM including the letter 'e' to
be spam? Should we then stop using that letter? No, of course not.
Other edge case may turn up. They are unlikely to make me abandon SPF
and SRS, but they are real problems that do have to be dealt with.
Yes. But not at the SPF side. That commercial package is broken and
should be fixed. Dito for forwarding as discussed in this message.
Thank you for the example, it works perfectly and supports my PoV.
Alex