On Mon, 2004-04-19 at 00:23, wayne wrote:
In
<1082273420(_dot_)4735(_dot_)11418(_dot_)camel(_at_)localhost(_dot_)localdomain>
Mark Shewmaker <mark(_at_)primefactor(_dot_)com> writes:
I would like to suggest the use of the SMTP DSN extension ORCPT
Hi.
The use of the SMTP DSN extensions has been discussed before, although
if I recall correctly, they were centered on the ENVID value rather
than the ORCPT value.
I've seen references to the fact that ENVID had been discussed, but I
haven't found any actual discussions beyond one-sentence
not-out-there-everywhere type comments.
(Anyone know a way to download the archives in mbox format? Searching
through a 3am wget of the spf archives (so the load shouldn't be a big
deal) didn't show any real discussions, but a simple mbox download would
have been quicker, easier to search, and, well, more polite.)
2. ORCPT was first introduced in RFC1891, eight years ago.
Unfortunately, writing up standards is often not nearly as important
as writing up code. A very quick check seems to indicate that
sendmail and MS-exchange have DSN, but postfix, qmail and exim
don't. Daniel Burnstein, the author of qmail, seems to think that DSN
is obsolete and that VERP is better.
Have you checked into how widely supported DSN actually is?
A did a cursory glance through the newsgroups that led me to the
incorrect conclusion that postfix, qmail, and exim all supported it, and
that it was just the closed-source MTA's that still sometimes didn't.
Apparently I'm wrong. I'll look back into it again in more detail.
Thanks for pointing this out.
(I did notice that at least one pobox mx answered claims to be Postfix
(I think), and doesn't include DSN in the EHLO response, so it was sort
of a bit funny to DSN. I had actually assumed that they had disabled
it, not that it wasn't available in postfix.)
Or to be more precise, I would suggest changing SPF to:
1. Allow recipients to set a Recipient Policy in which the
Recipient can choose between saying one of these three
things: (I'm speaking loosely here.)
I think being able to do per-user SPAM filtering is a good idea, but
they are really local policies rather than something that needs to be
addressed in the SPF spec.
I don't think we really have a disagreement here--I think it's more that
I worded things a bit loosely.
SPF is per-user already in the sense that sites can let individual users
decide to implement it. That's the sense I really meant it.
Although I squarely fell into the "SPF should specify an specific result
and leave no ambiguity for implementations to differ in their answers"
camp previously, and I still consider that to be the case for MAIL FROM
testing, I (obviously) don't see why there would be a problem to define
the judgement on whether to accept an ORCPT value for further testing to
be allowed to be site-dependent.
That way some sites can allow all ORCPT values, (again, equivalent to
SRS now effectively), and others can allow their users to pick from
choices. The part of the standard that tests for the Sender Policy
would still be rigid, and the part of the standard that tests for
Recipient Policy would be, well, more left up to the recipient.
2. Then, when running SPF tests on incoming emails:
o If there is a value of ORCPT that matches the Recipient's
Policy, run an SPF test using that ORCPT value.
How do we know that the envelope from is trustworthy just because the
ORCPT value passes?
Your question contains some hidden assumptions I'd like to address,
unfortunately in the form of what comes close to a rant. (It took me
longer than I'd like to admit to par down my previous email before
sending.)
Forget my ORCPT suggestion for the moment, and step step back to
reconsider the original SPF notion that:
o SPF allows for a domain owner to publish a policy statement that
explains how the rest of the world can tell if the owner has
authorized a Sender to claim to be from his domain.
o Forwarded messages (without rewriting) will naturally FAIL these
test. (Ignoring corner cases like local forwarding and such.)
o So, then end recipient of an non-rewritten forwarded message
will find that the message FAILS to meet the conditions of the
Sender's Policy.
Instead of trying to workaround the problem with return-path rewriting,
what happens if you accept the failure of a forwarded message to meet up
to the requirements of the original Sender Policy as a given?
Then you're left with the fact that the end recipient will *still* want
to get the (legitimately forwarded) message anyway!
I think we've been so steeped in the mindset of handling everything in
terms of a Sender's Policy Framework, ("We've got to be able to rewrite
the MAIL FROM argument to force-fit it into *someone's* Sender
Policy!"), that it's been hard to step back and and consider a pair of
equally possible alternate conclusions that:
1. Yes, a forwarded message will almost always FAIL to meet up
to the Sender's Policy, but
2. The *Recipient* can have a policy that under some conditions
they'll want to accept the thing anyway.
In any event, it's the Recipient's policy that's really all-controlling.
A Recipient can:
1. Accept everything.
2. Accept mails with an even number of characters in DATA.
3. Accept/reject based on SPF
4. Accept/reject based on SPF only for users who've selected
that.
...
It would be nice if a recipient could accept/reject based on SPF, except
for their friends or known forwarders--and they could do that if they
could identify people who claim to be their friends and forwarders and
then verify that they're not forged friends and forwarders.
But SPF lets them check for forgeries--so all they really need is some
note in the forwarded emails that reads "I claim to be forwarding this
message from your bob(_at_)forwarder(_dot_)com account".
If they had that note, they could verify THAT claim instead of the
Return-Path claim and the RECIPIENT would be happy.
So instead of trying to rewrite/forge/lie with the Return-Path in order
to fool the recipient into thinking the Sender was someone else, why not
just respect the fact that the recipient can make up his own mind on
things, and provide the data he'd likely be looking for in order to make
the decision?
And obviously I wonder if ORCPT can provide this data.
So...to get back to your question, if I as an end recipient decide that
I want to accept messages with a non-forged ORCPT of a certain value,
then IMHO that should be it, end of story.
If you ask why I as an end recipient think the envelope-from is
trustworthy--I don't, necessarily. I may in fact have a spam-honeypot
email address set to a forwarded address, and forward everything sent to
it to my account elsewhere. In that case, I doubt that the owner of the
domain claimed in the original MAIL FROM would have authorized its use
by the actual (forging) sender by the domain's policy, but with
ORCPT-checking, I can that the ORCPT value is acceptable according to
*my* policy, and check the ORCPT for forgeries.
Now, the more instant answer to your question, the one that doesn't
rudely assume that you have incorrect hidden assumptions, is that if I'm
a normal not-wanting-forged-emails user that's using a forwarder, I am
likely to have the forwarder do SPAM checks and SPF checks that validate
the original MAIL FROM, and then accept emails that forwarder emails me,
validating such emails based on the SPF policy that can be gleaned from
the ORCPT value.
[snip]
What is the advantage of checking the ORCPT hand having a local
(per-user) whitelist based on it rather than just whitelisting the
forwarder?
I'm not an expert on DSN, but shouldn't an email forwarder have a
one-to-one relationship between the email address it accepts email on
(the ORCPT value) and the email address it forwards to (the RCPT TO
value). That is, sending email to foo(_at_)pobox(_dot_)com should always send
email to bar(_at_)example(_dot_)com (RCPT TO value) with an ORCPT value of
foo(_at_)pobox(_dot_)com(_dot_)
So, couldn't the bar(_at_)example(_dot_)com just whitelist pobox.com? Yeah, I
guess it is possible for an email forward to start spamming, but there
are other ways of dealing with that.
It wasn't really spamming I was thinking of--I was just considering the
idea of someone or a group of people deciding to be annoying.
If you can technically say that you'll only accept forwards with ORCPT's
of "myaccount(_at_)pobox(_dot_)com", then you can know you can prevent yourself
from getting forwards from "annoying_person(_at_)pobox(_dot_)com", and thus you
know you can be lazy and decide to accept all forards from "@pobox.com".
Now, granted, pobox.com wouldn't let annoying_person be...annoying like
that for long I'm sure, so even accepting ORCPT's "@pobox.com" would not
likely be an issue for more than a minute or so after contacting pobox,
but other forwarders probably won't respond so quickly--and I probably
can't even really blame them. Someone wanting to be annoying can likely
forward mail from aol pretty to me easily, but handling complains on
that sort of thing isn't really aol's forte--it's not so exterely close
to their primary business as it is to pobox's. Few of aol's support
problems are likely to deal with that as a problem, so it would probably
take longer to find someone at aol to fix that problem than it would
take pobox.
(Lots of "probably"s and "likely"s there.)
So even if recipients are just a bit lazy and say they can accept
forwards "@pobox.com", the fact that this sort of system could allow
them to restrict the forwards to being from "my_account(_at_)pobox(_dot_)com"
means
one avenue of attack is less useful to annoying_person.
Also, given that ORCPT has a left-hand-side and a right-hand-side, I
didn't really think I should propose throwing away the LHS even if I
personally thought it would often be unnecessary.
Anyway, I like the idea of using an SMTP extension of some sort
instead of having to do SRS, but I suspect that we will have to do SRS
for quite a while. :-<
Thanks for considering it.
(I keep thinking that there has to be some other simpler and more easily
promotable solution than SRS.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com