ietf-mxcomp
[Top] [All Lists]

Re: HELO, IPR, A&R means new draft?; scope; Microsoft - (Re: DEPLOY - IP, HELO & touch count. )

2004-09-14 23:18:58

On 9/14/2004 4:53 PM, Douglas Otis sent forth electrons to convey:

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 obvious reaction to [John's] technique would be to spoof IP addresses of
known good MX servers in these records.
Yes, the technique won't work.  For folks unfamiliar with RHSBLs:
http://www.rfc-ignorant.org/how_to_domain.php has usage info for their RHSBLs.
Ditto http://www.securitysage.com/antispam/rhsbl.html;
http://www.scconsult.com/bill/dnsblhelp.html#3-8

<>As I said before, the mailbox
domain within SPF and Sender-ID is worthless for reputation checks.

<moved, also by Doug:><>
<>

<>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.

<ditto>

Let me clarify.  Neither Sender-ID nor SPF will support RHSBLs.

Doug, did you get my email - of a possible broad, strong example showing it falling down. If foo.dom's SPF/SenderID record lists just MX, and doesn't send spam, how/why would a reputation service blacklist foo.dom?
e.g .
foo.dom.    IN    TXT      "v=spf1 mx -all"

=-=-=-=-=
On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey:

<Matthew Elvey said:>

Phrased differently:
....<why HELO>
This is a VERY interesting approach. [...]

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. : )
Right, it's not new. It just doesn't have Marketing Might behind it. Of course now it has an encouraging nod from AOL...unofficially, of course :)

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 reputation 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.
Carl- I'm curious as to whether you think AOL would take advantage of this flexibility if it was available. Is this planned use of HELO roughly what you thought it was?
    <snip>

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.
Cool, though to be fair: what's the upper limit on the number of DNS queries marid-mpr might require, assuming a malicious sender attempting a DoS?

<snip>

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.
Confusing paragraph, that.

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.
Very efficient.

...
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.
Folks agree/disagree with that?  (Applies only to SPF and SenderID.)

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!

Folks agree/disagree that MARID specs should cover how they will work with A&R services? (IMO blacklists and whitelists ARE A&R services.) The result codes from, e.g. sorbs - http://www.dnsbl.us.sorbs.net/using.shtml are more than a binary result - some BLs provide bitmapped result codes.
Doug: What do you think?


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.

Indeed. I have. It's hell slogging through the acronyms though - MCAL, MCNL, etc. I'll have to read it again in order to be clear on what goes where - A vs PTR vs APL... Just read BATV - glad to see it! Perhaps it could pursue a standards track - the 'Public Tagging' component means interoperability is important so it should pursue standardization.