On Tue, 2004-09-14 at 14:14, Matthew Elvey wrote:
This is a belated-due-to-to-travel follow-up to replies to this post:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03596.html
(Summary: Sender ID fails to be a solution that only requires sysadmin
action; it mandates end-user reconfiguration on a massive scale, because
it doesn't say that HELO checking should/must be done... The Microsoft
IPR are too encumbered...)
The issues I raised in my last post were appropriate during a last
call: They were raised earlier, and there were strong indications that
they would be addressed (e.g. the Unified SPF discussion and
documents). Yet they were in fact not addressed by the specs that were
in last call.
"=-=-=-=" <-- topic separator
I think John Leslie said that under SenderID, a domain's reputation
would be looked up by looking up the IPs its SPF2 record lists in an IP
blacklist.
I think John is confused - that's not what I am expecting. I'm
expecting the domain itself to be looked up in a RHSBL. That's Right
Hand Side Block List. (John's idea could prove useful, but I'd be
surprised if it, e.g., scored well if coded as a SpamAssassin rule and
evaluated)
The obvious reaction to this technique would be to spoof IP addresses of
known good MX servers in these records. As I said before, the mailbox
domain within SPF and Sender-ID is worthless for reputation checks. In
this respect, John is right in this case. The address must be used for
any checks or reputation assessment.
=-=-=-=-=
On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey:
<Matthew Elvey said:>
Phrased differently:
Sender ID fails to be a solution that only requires sysadmin action; it
mandates end-user reconfiguration on a massive scale, because, IIRC, it
doesn't say that HELO checking should/must be done. Hence I (of
elvey.com) would have to get all my domain's end users to use MSAs that
I (as DNS admin of elvey.com) knew about. For fastmail.fm, my email
provider, who hosts mail for thousands of domains, they would have to
support this for each user of each domain!) If HELO checking is
mandatory, they just send HELO fastmail.fm, and ensure that fastmail.fm
has a good reputation.
This is a VERY interesting approach. I think you are saying, scratch using
DNS for "listing Domains allowed to be sent by an IP address", and instead
have the system admin "program" those domains into the MTAs (e.g. a config
in sendmail). The MTA would HELO the domain they are about to send for, IF
THE MTA is told they are allowed to send for that domain in the first
place
- otherwise the mail is rejected (and likely much closer to the submission
MTA/MSA).
This sounds really cool. But I am an engineer and must always ask, what is
wrong with this and why has it not been thought of before?
It has been considered and there is language within CSV that
accommodates this approach. : )
Lets see, forwarding cases....might work here with some PRA/Submitter type
changes. Not a huge problem.
Forwarding case would work GREAT - no PRA/SUBMITTER needed. Yes, 'The
MTA would HELO the domain they are about to send for.' This domain
wouldn't have to match the MAIL FROM or PRA or SUBMITTER. It would
simply need to be a domain that had an appropriate reputation for the
content. E.g. if we assume AOL is responsible about ensuring very
little spam is sent using the servers it authorizes to do HELO aol.com,
and sends all email through these servers, then there is no forwarding
to worry about. Helo aol.dom would trigger a reputation check on aol.dom
as used in HELO, the repuation would be excellent, and no further checks
would be necessary - the From: domain or PRA could be elvey.dom or
DomainWithNoSPFrecord.dom.
Here's a sophisticated possible scenario that provides more flexibility:
AOL might do HELO goodAolPayingCustomer.dom, if the mail is from one,
and the customer hasn't recently sent a ton of email. It might use HELO
aolSuspectCustomer.dom where appropriate, before cutting the customer
off completely. AOL wouldn't have to pay to give
goodAolPayingCustomer.dom a good reputation; it would deserve it. AOL
wouldn't have to cut off customers as often - it could limit use in a
less draconian way. Helo aolTrialUser.dom and HELO AOLFreeEmailUser.dom
would make sense, provided AOL provided and used dedicated IPs for such
mail and created the appropriate DNS records.
Just to clarify: the above is a sophisticated, enhanced solution that
HELO-based reputations make *possible*. It will be perfectly OK for an
MTA (or all of a domain's MTAs) to have one domain that goes in all
HELO/EHLO commands sent, and this is likely to be the usual case, and
will work well.
OK so what is wrong with this?
Well, no criticism so far, other than from Jim, which I've addressed
thoroughly.
-Carl
On 8/26/2004 11:12 AM, Jim Lyon accurately summarized and conveyed:
Matthew Elvey raises two points that I summarize as follows:
1. If you don't know what a domain's outward-facing MTAs are,
it's really hard to build a SenderID record. (And he estimates
that half of his customers are in this boat.)
True.
2. If instead of SenderID, we'd merely authenticated the HELO name,
and built up reputation systems that say whether particular
HELO names behave reasonably, these people's lives would be easier.
It's true, but it's a whole lot weaker form of authentication.
Please, I've already explained why it is stronger. If you're going to
say it's weaker after it's been explained WHY it's stronger, please
respond to the provided arguments. You need to do this or you drag the
conversation to the <Yes it is. No it isn't. Yes it IS...> level.
[edit: it looks like you've had the argument with Doug in this thread.]
I find it difficult to believe people will allow themselves to be harmed
by reputation services that hold them accountable for any MTA authorized
to send their mail.
I can imagine the conversation: (ac=angry party, rs=reputation service)
ap> Why in the h*ll did you put by domain on your rhsbl?
rs> There are incidents where this mailbox domain was used in spam.
ap> I never sent this cr*p!
rs> Ah, but you authorized the MTA that sent it.
ap> What authorization caused this problem?
rs> This will require investigating and a fee to resolve.
ap> Too bad Sender-ID does not identify the authentic sender!
I don't care whether a mail server is who he says he is, I care
whether he's authorized to send the message he's trying to send.
May I add that the marid-mpr draft can safely answer this question
within a single DNS query and not require the potentially hundreds
needed by Sender-ID or SPF.
Can we please graduate to more advanced banter than this? The charter
says what we care about. (It's adequate, even if the main goal is to
address spam, including joe-jobs, phishing, etc.)
The first half of the sentence states that you don't care about the
server's Identity, and I know that you in fact do; SenderID relies on
Identity. I fail to find a logical argument for ignoring HELO. You
imply you care about the body of the message, but SenderID doesn't look
at the body. (Why are you calling a mail server a 'he'? It's confusing.)
Jim Lyon later also said:
Authorization: The SenderID test determines whether the sending MTA is
authorized to send mail that claims to come from a particular domain.
This is a too-short definition (which you later improved upon); it's
actually not accurate. A mail message can claim to be from several
domains.
Jim later clarified things:
The identity being authorized is the sending MTA's IP address. The
action being authorized is to send a message on behalf of the PRA.
The organization doing the authorization is the domain of the PRA.
PRA, if adopted, will be manipulated by spammers by the insertion of
forged headers. (I'm working on an example.)
=-=-=-=-=-=-=
Andrew Newton wrote:
> On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote:
>> A HELO scope would be useful.
> That is already being covered by the CSV proposals.
No, not even close. -protocol with CSV, and -protocol with a HELO scope
would be EXTREMELY different, can't believe you don't see this, Andy!
Please consider the need for two steps in this process. One,
authenticate and validate the authorization of the MTA EHLO name. Two,
obtain a list of authorized EHLO names referenced by the mailbox domain
being examined. This list can be either nominal or comprehensive
without the nominal case inviting spoofing. In which case, CSV remains
"as-is". MPR records are much simpler and easier to maintain and obtain
than scripts for SPF or Sender-ID.
I would suggest avoiding sequential TXT scripts needed with either SPF
or Sender-ID as being unworkable. CSV used in combination with MPR and
BATV provides all the features claimed by either SPF, SRS or Sender-ID
without disrupting email to the same extent.
There is another issue with either SPF or Sender-ID records. CSV and
MPR are named based solutions that work within the natural scale of DNS
and only require single non-sequential lookups. SPF or Sender-ID
require either extensive iterative references to record names to obtain
addresses, or the repeating of IP addresses in a script form. The
maintenance of such a list will be high, or the relative overhead to use
such a list will be high or both.
As Meng said, if HELO and SUBMITTER (modified to not use the encumbered
IPR) always override MAIL-FROM, then there is no need for SRS.
With a public version of BATV there is no need for SRS either.
In addition to/as part of the security review of SenderID:
I think it's necessary that a number of MAYs and SHOULD [NOT]s turn
into SHOULD [NOT]s and MUST [NOT]s. There is far too much waffling -
MUST [NOTs] MUST be used whereever there isn't a compelling reason not
to. IETF standards demand it.
Also, the way that Accredidation and Reputation services are to be used
is essential. It belongs in a BCP, which should specify BFP (Best
Future Practice) for how various tests should be interpreted and acted
upon. SPF claims to address the spam problem (according to text that
was on the spf.pobox.com home page) so the Accredidation and Reputation
services that are a necessary component to this solution must be
specified. An incomplete spec that lacks these things has no business
aspiring to be an Internet Standard. How can a spec that is grossly
incomplete be properly reviewed by us or the IESG? It can't!
E.g. John Leslie is quite confused about how A&R might work, or I am, as
mentioned above.
Let me clarify. Neither Sender-ID nor SPF will support RHSBLs.
=-=-=-=-=
Sorry these comments weren't more timely.
So, who's for a new draft with two scopes: HELO and MAIL-FROM?
(Wait, how about a third scope: From:? This would be something
phishedbank.dom might want to use to indicate that it would rather break
forwarding than allow its domain to be used in From: without its
authorization. Do folks think phishedbanks would actually use such a
scope? (I'm reopening a closed can of worms; perhaps given the failed
last call, it's time to do so.))
You will find that the marid-mpr draft does allow the protection of the
From and the MAIL FROM and is a good alternative to the PRA approach.
-Doug