Le mercredi 4 Août 2004 01:49, Douglas Otis a écrit :
- Question : SPF currently has the extremely useful and flexible
"exists" mechanism, that, combined with its built-in macro-expansion,
allows for designing very fine-grained and flexible exceptions to the
general SPF rule for a given domain, i.e. per user and subnet.
If using CSV, any exceptions would be per hostname. As an alternative
to using the exists, which checks for yet another DNS record, simply set
up differing subdomains with different rules. [...]
They could also setup a subdomain that adds this new domain.
When you buy a pair of shoes, do you actually look for shoes that fit
right to your feet, of do you try to force your feet into a given pair ?
A technical solution needs to fit with user needs. You can't ask a company
"Oh, you just need to change the way your email system works, create a
dozen of subdomains, change all of your email addresses, and print new
business cards, and then it will be right for CSV".
You are referring to a desire to restrict the use of an address to their
servers. This may be good for a large enterprise such as a bank wishing
to constrain where these messages may emerge. This restriction depends
upon the receiving MTA checking for this request, or it means nothing.
The normal use of mail today does not offer this restriction. Whether
there is such a constraint, making the EHLO domain visible would still be
helpful in guarding against spoofing.
The feet needing shoes do not wish to have a nail poking them in the heel.
SPF or Sender-ID puts a burden upon those using mail in a normal fashion.
That would be sending mail without regard to the point of access. SPF or
Sender-ID allows this mode, but at a high cost. Domains not imposing this
new restriction should then expect their DNS record to be used as a spam
exploit. If big-bank.com wants to have exceptions to this rule, then yes,
I am suggesting this be done by using a subdomain. I would not expect a
mail list name would need to appear on someone's business card.
SPF allows a kind of flexibility that permits adapting the SPF records to
the existing infrastructure, far better than having to adapt the
infrastructure to fit the requirements of the new authentication system.
SPF and Sender-ID breaks forwarding as example. Sender-ID decided to
limit the time these extensions may cause, but this solution ignores the
UDP exponential back-off requirement. DNS records must be constrained and
not allowed to grow to such an extent. One or two sequential lookups per
message is far better than hundreds as now defined. SPF limited recursion
and not the number. For a very brief period, Sender-ID limited the number
of queries. This is out of control, in my opinion.
If big-bank.com wants to have different rules for different users, giving
these users a different subdomain is not asking to much. SPF and
Sender-ID want all forwarding and "exploding" list servers to change.
That is a shoe that does not fit.
If a MARID system (any flavour) necessitates that a number of domains have
to change their infrastructure architecture significantly for using it, it
will be a show-stopper.
You are describing the effect of imposing a restriction on a domain, but
are then unhappy with problems this restriction may cause. It seems fair
to have those making the changes, endure the impact. Sender-ID and SPF
impose their change on others, and ask domains, without any desire to make
these restrictions, to suffer.
Employing CSV and making <From:EHLO> a visible "Mailer-ID" will not impact
anyone, but will stop spoofing, phishing, and curtail Trojans. That can
not be said of Sender-ID or SPF. Frankly, any large enterprise that wants
to nail down where their emails emerge should also have VPN to allow these
messages to come from the machines they designate.
The advantage of current blacklist systems is that no one has to pay
for getting blacklisted ;-) and, if some blacklists are commercial,
such as MAPS, you need to pay to use and query them, not to be listed
in them or not...
What? There is no relationship between a MAPS client and those that get
listed. There are several large ISPs that would testify to that! The
millions of dollars spent servicing legal defenses (never going
anywhere) forced MAPS into a paid service.
I never said that there was a relationship between MAPS clients and those
that get listed. You completely misunderstood my meaning, or I didn't
express myself clearly enough (sorry, english is not my language...).
There is no relationship with those that don't as well.
(Parenthese:
BTW, my own perfectly static and never-spammed IP got listed by MAPS-DUL
last month. It was unlisted within 24 hours after I complained, but it
_did_ cause me trouble, and for all the users of the domains I manage as
well. A friend's perfectly static IP (at the other end of France) got
listed by MAPS-DUL the same day, but it took him more than a week to in
the end get unlisted. He was really, but really, really pissed off with
this.
End of off-topic parenthese)
Yes, vetting by address sucks in a big way. I will say that the DUL list
is responsible for stopping the majority of the abuse, but is also
responsible for much of our service overhead. The information we get from
ISPs is not always perfect. Many don't know what is assigned.
The CSV approach would not step on the toes of the innocent as does
address blacklisting addresses. Blacklisting, as will CSV, curtails spam.
Proponents of Sender-ID must not claim to provide a reduction in spam,
spoofing, or phishing. CSV can provide a reduction in spam, phishing,
and spoofing, without any additional records added to impose domain
restrictions. Just show the user the <From:EHLO> and that would be a
world of improvement over today's problems. It would not require any
changes to anyone's use of mail, as does Sender-ID. If you wish to add
the ability to contrain what EHLO can post a From domain, then those
making this change may need to do things a bit differently, but that is
only fair. These records will never become a spam exploit as will
Sender-ID or SPF records.
-Doug