Hello!
On Wed, Oct 13, 2004 at 12:05:54PM -0400, Stuart D. Gathman wrote:
On Wed, 13 Oct 2004, Hannah Schroeter wrote:
About 75% of the SPF records in the .com TLD end in -all. I would say
that it is the current practice, although certainly not the
universally adopted practice.
Have I missed something (specifically, a solution for that already in
widespread implementation and deployment) or do they just ignore the
forwarding problem?
Forwarding is only a problem for mail recipients who check SPF and
do not make provisions for any forwarders they have set up.
Ok. Say I'm a not so clever customer. I pay provider A for
forwarding services, as A offers cool mail addresses. I pay
provider B for POP3 services under an un-cool mail address.
So I setup A to forward mail to B.
A and B are different providers, i.e. don't have any special
cooperation, technical or otherwise.
Now X sends mail to my cool(_at_)a address. X's provider has strict
SPF records setup, i.e. especially with -all instead of ?all or
~all.
Suppose A doesn't do neither SPF nor SRS, but B checks SPF.
Bingo.
Forwarders are set up by the mail recipient - and are the responsibility
of the mail recipient. Mail senders publishing SPF records should not
have to worry about forwarding. (Unless you count greeting card sites
which let users enter an arbitrary MAIL FROM. This is the senders choice, in
which case you'll have to list such greeting card sites you use to send mail -
or use ?all).
I might be a simple customer (I am not in fact, but for the scenario).
I.e. I don't know about specifics of SPF and forwarding. So why should
I, in this scenario, worry about SPF and forwarding and SRS and
whatever? I'm just buying a few services from different providers.
And if I'm a sender, I might not have the ability to change the
SPF record for provider.foo, just because I, using
sender(_at_)provider(_dot_)foo,
want to use greeting card sites with my legitimate mail address as
sender.
So again a reason for either not SPF or using at most ~all instead
of -all.
Even a large ISP has no excuse. They complain that they don't know
what forwarders their users have set up. Maybe so, but they can:
1) provide a web based configuration page to list forwarders
Ok, but how does the plain user know that hir forwarder mail address
might be foo(_at_)forwarder(_dot_)bar, but the site to allow an exception would
in
fact be mout.forwarder.bar?
2) default to *not* reject SPF fail for users who have not configured
their forwarders (but still add the Received-SPF header).
Makes more sense. But then that amounts to interpret -all not much
differently than ~all.
3) Give user who have configured their forwarders the option of
rejecting messages that fail SPF.
Can make some sense, at least if the big provider adds explanations
enough for normal customers to understand the implications of this
option.
When configuring a forwarder, all you need to know is whether the forwarder
supports SRS.
Yeah. But the plain customer might not know that.
For non-SRS forwarders, accept all mail without checking SPF. Hopefully,
you (or your user) have selected a forwarder that checks SPF before
forwarding.
For SRS forwarders, check SPF.
Right.
In any case, when forwarders are listed, do not accept SRS mail unless
it is from a listed forwarder. Otherwise, you'll get lots of forged spam
from an SPF compliant spammer site that puts SRS in the MAIL FROM.
Ya mean things like
SRS0=(_dot_)(_dot_)(_dot_)(_dot_)=(_dot_)(_dot_)(_dot_)(_dot_)(_at_)spammer(_dot_)com
as envelope sender,
listing a fake address in the SRS part? But then spammer.com gets
the bounces first still, because if another site bounces, it doesn't
shortcut the SRS (because it can't check the timestamp/hash).
And whether a spammer un-SRS-es bounces of such spam, or whether
he just sends further original spam to that faked address, what
does that matter?
And if the spammer is only a customer of @spammer.com, he can't
generate valid hashes (with more than the probability of a randomly
right guess).
For ISPs, I hope it is clear that this configuration is PER USER.
The decision on whether to reject an SPF fail is delayed until after
RCPT TO, so that per user configuration can be consulted.
Would make sense. But will all sites keep to that kind of policy
in future too?
Kind regards,
Hannah.