Ellen,
[...] they allow the customer to
choose the From: address that is used in their outbound emails so that
the email will be recognizable to its recipients. In general, this email
address will be an address from a large ISP (e.g.
joesbikeshop(_at_)yahoo(_dot_)com), and is usually the primary electronic
identity.
So the body From: address would be joesbikeshop(_at_)yahoo(_dot_)com, but the
sending agent would be the 3rd party service (e.g. outsource.com). [...]
With SSP in play, once the ISP (e.g. yahoo.com) decides to publish an
SSP record things start to go downhill. The above configuration will
always trigger a lookup since the signature will never come from the ISP
domain, and the Verifier will only look for the SSP policy in the From:
address domain (yahoo.com). [...]
In other words, once the major ISPs start publishing SSP records there
will be no way for people matching the above profile to avoid having
their mail marked as suspicious by SSP unless they stop using their ISP
email, which is most cases is the one that's recognized and trusted by
their customers. [...]
Douglas Otis writes:
Correct, but such a domain is unlikely to publish a restrictive
policy. Such a policy would reduce the utility of the domain's email
by making use of mailing-lists problematic.
Here is my heretic view: in my opinion it is pretty much irrelevant
what SSP is published by a large ISP such as yahoo.com. Recipients
are free to associate any reputation (or spam score) to received mail,
independent, or in accordance, or in contrast with a published SSP.
Let's look at some data I collected from mail that we received (at
the ijs.si institute) during last two months or so. I'll concentrate
on yahoo.com (and gmail.com) mail as it was mentioned in the posting,
and as it offers a perfect example of what I want to show.
On all mail with a From address (_dot_)(_dot_)(_dot_)(_at_)yahoo(_dot_)com,
some is coming
directly from yahoo servers and is signed by DomainKeys, and
the rest is coming from other hosts, and as such is not signed.
The average SpamAssassin score (values below 1 are clear ham,
higher values, e.g. above 5 are spam) across all yahoo.com-signed
mail is around -1, i.e. very much clean and trustworthy.
Average spam score for all non-signed (or broken signature) mail
with a From address being yahoo.com is 27, i.e. outrageous spam!
I'd be an irresponsible mail administrator if I'd treat
yahoo.com-signed mail the same as other unsigned mail claiming
to be from yahoo.com but failed validation. It is natural to
treat as second-class all mail not bearing a valid yahoo.com
signature (e.g. assign few spam points to it), IRRESPECTIVE OF
SSP which might have been published.
With gmail.com this is similar, although less extreme:
- valid gmail.com signature, spam average = -3.9
- no valid gmail.com sign., spam average = +3.2
This demonstrates that these two service providers do take
their reputation seriously and they do take action on cases
where one of their mail accounts gets abused for sending
fraud or spam. Recipients benefit from their efforts only
on mail bearing a valid post stamp by an ISP.
As a side-note, the non-repudiation offered by signatures
facilitates the ISP's task of weeding abuse reports
into ones which can be acted upon (true mail account abuse),
and those which can not be acted upon, when a spam sender
just 'borrowed' a domain name but send mail directly.
I have a good experience with yahoo.com and their reacting
to every qualified abuse report I send them (once you
learn they can't deal with attachments but need original
mail in-line :)
So back to original topic:
- I think any user of a valid yahoo.com or gmail.com account would
be ill-advised to send his mail directly, instead of through the
native domain of his sending address. This is true today, and
will be even more pronounced in the future. Regardless od SSP.
- nowadays where practically all modern MUA clients are able to
authenticate on submitting mail, and mail servers not offering
some form of submission verification (SASL, TLS, pop-before-smtp,
IP checks, ...) are a rare bird, it is a poor excuse not to submit
mail through a native domain's mailers, even for roaming or home users.
Note that this distinction between mail coming through a native
domain and the rest is not specific to DKIM or to DomainKeys,
similar is achieved by other means, such as SPF, or even checking
the reverese DNS on an client's IP to fall under the domain claimed
in From.
Jim Fenton writes:
[...] I am not aware of any consumer
ISP that, as part of its Terms of Use, requires its customers to send
outgoing mail through its mail servers. There might be some that have
this requirement in order to do more effective outbound spam filtering,
but I'm not aware of them. In the absence of such a requirement, it
would be improper for these ISPs to publish an 'all' or 'strict' SSP,
as that would be, in effect, imposing a restriction that wasn't there.
There needn't be any such explicit requirement. Senders will eventually
learn that it is to their best interest to submit mail through their
native domain.
Customers sending mail using their personal addresses through their
company's mail infrastructure, or from a hotel that blocks port 25,
would have the same problem.
I hope this will be less and less of a problem. Mail submission
port is 587, not 25. While there are good reasons to block
outgoing connections to port 25, nobody in its good will should
be blocking outgoing connections to 587 (if they allow outgoing
connections to port 80). As a last resort, there is always a web
interface to mail submission.
And as J.D. Falk said:
ESPs should think of this as an upsell opportunity, and encourage your
users to get their own domains so they can (pay you to) set their own
policies!
I fully agree.
Mark
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html