Re: [Asrg] What are the IPs that sends mail for a domain?
2009-06-22 14:18:01
On Jun 22, 2009, at 3:58 AM, Alessandro Vesely wrote:
As for forcefully disabling accounts, one needs a legal authority to
break a commercial agreement. For some reasons, they tend to move
quicker for child porn than spammers. Last time I talked about spam
to our postal police, the first thing he said has been "me too".
Since we lack police resources for snatches and rapes, I felt
arrogant asking them to go after my spammer, and gave up.
This suggests poor Acceptable Use Policies.
I don't follow how OpenId would help.
Stable identifiers might mitigate some vetting.
CSV was to offer a DNS record type that explicitly declared a host
as being an outbound MTA. This would not in itself prevent abuse,
but would help to determine which compromised systems might be
sending email and resolving which domain is administrating the MTA.
It didn't help retrieving the responsible domain, though.
Furthermore, it didn't do ranges, thus making it laborious to deny
sending to a bunch of hosts. In addition, CSA spec curiously had a
"MAY" for an non-authorized host with a non-ignored target resulting
in weight 0.
The domain administrating MTAs ARE the truly responsible Domains. It
would be speculation whether an entity offering authorization actually
originated the messages. CSV was intended to affirm the SMTP
operation by a specific domain. Any CSA record not expressing an
affirmation MAY be assumed an indication of the host not being
authorized.
However, _client._smtp.domain-name records authorizing various
targets would be almost equivalent to setting SPF, or MX heuristics.
(I'll possibly add that to the next vhlo draft.)
Only the HELO mechanism of SPF comes close, but SPF itself does not
offer a means to limit the SPF record scope.
SPF does not work well at resolving a domain that should be held
accountable for a few reasons-
One reason is that it works the other way around: given the domain,
authenticate an IP address as a mail transmitter (thus implicitly
authorizing it to send mail).
Authorization does not indicate either administration or origination.
Any need for authorization records for acceptance will be extorting
the publication of records that might allow blame to be incorrectly
placed. Hardly a way to ensure providers remain accountable. :^(
a) risks high and impractical transaction overheads at attempts to
indirectly reference the customers of a provider.
I agree it is more complicated than the average users need.
Presumably, the spec is so for being usable in a wider number of
cases. 10 lookups, however, seems reasonable to me.
It is actually eleven TXT SPF records that might be needed. The SPF
spec allows 10 mechanisms, where there might be a need for 10
subsequent target resolutions per mechanism . The actual limit of DNS
transactions is at 111.
b) may not qualify any specific IP address for a positive result.
Yes, especially if not used.
Even when used. The record can end in +all or use some exists(). SPF
also allows the use of macros. These macros can be cached, and yet
cause recipients to generate different transactions based upon
changing local-parts or IP addresses, for example.
c) Mail From or PRA references do not resolve which domain
administered the MTA or actually sent the message.
AFAIK, all discussions eventually reach the conclusion that the
receiving server does not know which domain administers the client
MTA. FWIW the old ietf-marid-csv-csa asserts that
The SMTP [RFC2821] [RFC0821] protocol permits a client to declare
its affiliation, by asserting a domain name in the HELO or EHLO
announcement.
SMTP (RFC 5321) section 2.3.5 does not stipulate the resolution of the
domain asserted by EHLO as using A, AAAA or MX records. It also
allows use of address literals. Section 4.1.4 then indicates
resolution failure of the EHLO domains or mismatch of address literals
MUST NOT be cause for refusing messages. Likewise, SPF also fails to
impose negative assertions for ELHO domain failures for Mail-From or
PRA domains, of course.
which is wrong. EHLO only allows it to declare its identity.
Declaring the affiliation is VHLO's raison d'être.
Since VHLO can be asserted by bad actors, there is no reason to trust
the guidance offered.
At any rate, forwarding -when MAIL FROM and PRA differ- requires a
framework different from SMTP to administer legitimate use of third
parties' email addresses. Classic mailing lists (as this one) comply
with various privacy laws, but most direct marketing lists and
users' .forward files don't.
Trusting the MTA via CSV/CSA does not impact message handling, unlike
problems created by Sender-ID and SPF.
d) holds customers of a provider accountable for the provider's
stewardship without any solid evidence of their involvement.
See below (at Why do you so often mention authorizing a provider?)
Most domains outsource email services. This is a growing trend as
email becomes more heavily abused.
Who said providers need to be criminal for naive users to be harmed
by SPF? A recipient may check PRAs, where providers may check Mail-
Froms.
Formally, SPF only recommends to check MAIL FROM. Any other use of
the underlying mechanism is just heuristics.
The lackadaisical attitude ends abruptly when reputation is misapplied
as a result of unverifiable assumptions of message origination when
erroneously based upon authorizations. This would be extending SPF
well beyond its intended purpose.
Once a user's domain reputation is damaged due to receiver error,
how can reputations be restored and then protected?
That has nothing to do with SPF.
Any negative assertions based upon SPF might be misapplied against
PRAs not protected by the provider. Misapplication of negative
assertions might also be due to SPF when Mail-Froms are also not
protected by the provider. Have you ever seen a SLA that stipulates
PRA or Mail-From exclusivity?
When asked in the past, those customers are advised to obtain their
own IP address.
If responsibility were attributed correctly, this wouldn't be needed
any more. Of course, if I had an address @spammer, I'd have to share
their fate, but my address is my choice.
If the IP address were only associated with that of the MTAs, users
would be able to seek services from any other provider. When a
provider's lack of stewardship impacts user's domains, then users are
left without resource, while the provider remains free to seek more
victims.
It is wrong to hold someone accountable for authorizing a provider
once authorization becomes a requisite for acceptance. Users are
thereby extorted into assuming risks well beyond their control.
Why do you so often mention authorizing a provider?
SPF is a scheme aimed at authorizing providers and thereby shifting
blame.
If I use a vanity address I have to trust an ESP who provides that
service and set MX and SPF RRs accordingly.
Why do you feel there is a need to publish SPF records?
The ESP may or may not be my connection provider. The risk is
related with choosing the ESP correctly, so that trust is well put.
That trust is not different for users of an existing domain, who
don't control the domain, but have to trust its admins.
Of course, trusting an ESP to keep incoming email confidential is
important, and is often covered in SLAs and various laws. But why
are users required to blindly trust that email providers will filter
other users outbound email? It is unlikely that this filtering is
covered by SLAs or by various laws.
Instead, providers should be held accountable by requiring CSV
records with a limited number of EHLO host names over time.
But the targets of those records need an address too. What's the
difference between writing an IP number in an SPF rather than an A RR?
CSV is only about who is administrating the MTA. It has nothing to do
with who might be inadvertently held responsible based upon Mail-Froms
or the PRAs.
This approach better defends receiving MTAs from abuse with lower
overhead, and better controls DNS related exploits that threaten
the entire Internet.
All of them rely on DNS, and some posts in that "DNS over SCTP"
thread showed that various people think just of http when they
figure out "typical" DNS usage... :-(
Unfortunately, when risks associated with SPF with respect to DNS was
explained, SPF advocates expressed distain for DNS.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Asrg] What are the IPs that sends mail for a domain?, (continued)
- Re: [Asrg] What are the IPs that sends mail for a domain?, Douglas Otis
- Re: [Asrg] What are the IPs that sends mail for a domain?, Alessandro Vesely
- Re: [Asrg] What are the IPs that sends mail for a domain?, der Mouse
- Re: [Asrg] "Affiliation", John Leslie
- Re: [Asrg] "Affiliation", Alessandro Vesely
- Re: [Asrg] What are the IPs that sends mail for a domain?,
Douglas Otis <=
- Re: [Asrg] What are the IPs that sends mail for a domain?, Seth
- Re: [Asrg] What are the IPs that sends mail for a domain?, Ian Eiloart
- Re: [Asrg] What are the IPs that sends mail for a domain?, Douglas Otis
- Re: [Asrg] What are the IPs that sends mail for a domain?, Dotzero
- Re: [Asrg] What are the IPs that sends mail for a domain?, Douglas Otis
- Re: [Asrg] What are the IPs that sends mail for a domain?, Ian Eiloart
- Re: [Asrg] What are the IPs that sends mail for a domain?, Ian Eiloart
- Re: [Asrg] What are the IPs that sends mail for a domain?, Ian Eiloart
Re: [Asrg] What are the IPs that sends mail for a domain?, John Levine
|
|
|