gmane.ietf.asrg

Re: SPF's helo identity as a reporting target

Douglas Otis — 2012-05-14T17:41:12

Dear Alessandro and Chris,

Since RFC821, HELO/EHLO was defined as FQDN SMTP hostnames.  There is no 
reason additional policy assertions such as those proposed for DMARC 
could not include authenticated email EHLO/HELO acceptance with a 
hostname from their domain, whether by a forward reference to an address 
list, or an SPF resource record.  The domain validated would be 
determined by the domain of the SPF record and not by an SPF mechanism 
as Chris suggested.  The goal of DMARC is to offer a safe method to 
reject messages in a way not likely to create support calls for 
receivers.  A policy that can be extended to individual SMTP servers 
controlled by domains making compliance assertions should offer safe 
rejections having lower cost than message filtering or rejections based 
on the SMTP mail parameter.  The mistake made by DMARC was not 
considering HELO/ELHO alignment against the parent domain rather than 
the hostname.

Regards,
Douglas Otis.

Re: SPF's helo identity as a reporting target

Alessandro Vesely — 2012-05-14T14:34:43

Whatever the intent, I should get your permission before asserting
that your server serves me.  Shouldn't I?  Then, yes, I suppose some
judges still have difficulties understanding Internet protocols.


I don't have specific experience, but it seems to me that when
spammers leave enough evidence behind them they can be taken to court.


You're right.  Rejecting is cheap, but still bears a cost.

Re: SPF's helo identity as a reporting target

Rich Kulawiec — 2012-05-14T14:22:39

On Sun, May 13, 2012 at 11:29:19AM -0400, Chris Lewis quoted:

+1, and let me add:

One of the many reasons to make the HELO consistent with the FQDN is that
it can be helpful in debugging.

---rsk

Re: SPF's helo identity as a reporting target

Chris Lewis — 2012-05-14T14:04:23


Who said anything about a deliberate DDOS?  Think of it as spam with
electronic countermeasures designed to confuse, confound and distract
the recipients and third parties.

Just like they already do.

"national laws ... openly breaks".  You can say that with a straight
face considering that 80-90% of all spam already does?


Big enough, the recipient site still loses before the 220.

Eg: think back to when AOL bounced instead of rejected for no-such-user.

Reporting targets, was SPF's helo identity as a

Alessandro Vesely — 2012-05-14T09:27:54

And how does it discover abuse contacts?


Yes, but it's not IP-based.  It falls back to RFC 2142 role addresses,
and relies on cooperative contributions (I think).


Thanks for the pointers, I'll take a look at them.


That would be a Good Thing.  However, it may appear a double-edged
sword, as it hides the network provider's abuse team.  One could
navigate whois records hierarchically, so if the virtual MTA operator
is a bad guy, the abuse contact at the upper level should be its
network provider.  This operation can be done recursively, but
homogeneity may obscure awareness.  That is, by climbing the tree all
the way up, one eventually gets at IANA's --which hopefully will never
be a bad guy-- but might not realize what role corresponds to each level.

Re: SPF's helo identity as a reporting target

Alessandro Vesely — 2012-05-14T09:26:05

More or less.


That's plain abuse, though.  There must be loads of national laws that
the owner of that zone openly breaks.  Isn't that too much risky from
a legal POV, considering its effectiveness is probably less than other
kinds of DDoS?

   220 wmail.tana.it ESMTP
   HELO goofy.example
   250 wmail.tana.it Ok.
   MAIL FROM:<>
   250 Ok.
   RCPT TO:<abuse< at >spammerdomain.com>
   513 Relaying denied.
   QUIT
   221 Bye.

Re: SPF's helo identity as a reporting target

Chris Lewis — 2012-05-13T19:56:49

Whoops, I meant:

_smtp.spammerdomain.com IN MX 0 wmail.tana.it


No.  The spammer says "helo spammerdomain.com".  Postmaster sends
complaint to abuse< at >_smtp.spammerdomain.com.

Where does that go?

Re: SPF's helo identity as a reporting target

Chris Lewis — 2012-05-13T19:55:08

It should.  But it doesn't.


Right.

As one said "the best thing about standards is that there's so many to
choose from" ;-)


That's an implementation detail.  There's no reason that they'd _have_
to.  Mine doesn't rely on whois for responsible domain or abuse contact.
 While it does the published RIR maps for allocations and countries, it
does no whois queries.

abuse.net's doesn't use whois for anything.  I don't think Cymru's or
Mynetwatchman's does.

It's _very_ hard to get domains from whois in an even remotely "global
sense", let alone abuse addresses.


"Proper management" of IP whois records is probably coming as unlikely
as it seems, so another reason for it wouldn't hurt.

Re: SPF's helo identity as a reporting target

Alessandro Vesely — 2012-05-13T18:49:08


That's not quite how helo authentication works.  When they say "helo
wmail.tana.it" the server looks up wmail.tana.it.

wmail.tana.it.  IN TXT  "v=spf1 redirect=tana.it"
tana.it.        IN TXT  "v=spf1 +ip4:62.94.243.226 -all"

They won't get a "pass" unless they are using that ip4.

Re: SPF's helo identity as a reporting target

Alessandro Vesely — 2012-05-13T18:40:32

So it would be an error-prone technique?  We are talking about
/postmasters/ extracting target addresses for abuse reporting, not end
users.  Shouldn't that imply some knowledge?

SPF records are going to sport a new ra= modifier, specifying an
address for reporting authentication failures, not abuse.  That may
bring further confusion, in fact.


Which one do you mean?  DNS lists like abusix get their data from
RIRs' whois databases.  In that case, virtual MTA providers would have
to restrict their choice of network providers based on proper
management of whois records, besides cost, bandwidth, uptime, support, ...

Re: SPF's helo identity as a reporting target

Chris Lewis — 2012-05-13T18:30:14


It doesn't help.

spammerdomain.com IN MX 0  wmail.tana.it.
spammerdomain.com IN TXT "v=spf1 ip4:0/0 -all"

[May not be exact, but you get the idea.]

10 billion cutwail spams heloing as spammerdomain.com later...

Re: SPF's helo identity as a reporting target

Chris Lewis — 2012-05-13T18:03:31

On the one hand, we have Klensin commenting on rejecting email based
upon helo validation (despite which, helo factors very heavily into
filtering anyway), versus _explicitly_ violating the RFC in a proposed
standard.

Klensin's argument doesn't apply to this proposal.  At all.




The reality is going to be is that since it relies on SPF to be valid,
few people would bother implementing it on the sending side, and there
will be more than enough people ignoring the requirement to SPF verify
before trusting it, that kabooms! will still happen.

There are other ways of doing this that doesn't require ancilliary gunk
like SPF. There's at least one IP-based DNSBL that yields the same data.

Re: SPF's helo identity as a reporting target

Alessandro Vesely — 2012-05-13T17:21:44

This has been discussed so many times that we don't need to do it once
more.  For one (John Klensin on Jan 2009):

  The 1123-imposed requirement (carried forward into Section 4.1.4
  Paragraph 6 of 5321) that messages not be rejected on the basis
  of a validation failure with the EHLO argument would presumably
  remain even if we deprecated 821 and client use of HELO.
  http://www.imc.org/ietf-smtp/mail-archive/msg05420.html


I'd agree that violating intents and/or practices is not a good start.
That seems to imply that it is necessary to use scripts to keep helo
names, IP addresses, and SPF in sync.  Would that be worth?

Re: SPF's helo identity as a reporting target

Chris Lewis — 2012-05-13T15:29:19

Uh what?

RFC5321:

Section 4.1.1.1:

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument clause contains the fully-qualified domain name
   of the SMTP client, if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is
   available), the client SHOULD send an address literal (see
   Section 4.1.3).

   ...

   The SMTP server identifies itself to the SMTP client in the
   connection greeting reply and in the response to this command.

Yeah, I suppose you could make all your outbounds have the same name (up
to whatever limit DNS imposes), but clearly this violates the intent.

And it's also very explicitly counter to industry practises/BCP.

Re: SPF's helo identity as a reporting target

Alessandro Vesely — 2012-05-13T09:58:40

I see nothing wrong if an organization uses the same helo name for all
its mailouts.  A helo name does not have to be a label of any DNS
record.  However, in case it has an SPF record it could be validated.


No, wait.  Didn't I say it has to get an SPF "pass" to get usable?
I must have considered it implied... my bad.

An idea is that if you offer virtual MTA services, you may want to get
complaints.  Unless you hijack each customer's abuse< at >, using helo
names might be more practical than relying on RIR's whois, depending
on your network providers.  But did anyone try that?  And if anyone
did, where do they publish their experiences?  Where do postmasters
learn to target complaints effectively?

Re: SPF's helo identity as a reporting target

Chris Lewis — 2012-05-12T17:46:55

It would be nice if it could be made usable.

This would tend to make a large organization having all of their servers
helo exactly the same way, which flies in the face of industry BCP (eg:
MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly
violates its intent.

Or they use wildcarded MXes.  Ick.  Makes "divisional" abuse addresses
very difficult.

Or use the registration level domain (lop off the non-registration level
FQDN qualifiers) - makes "divisional" abuse addresses impossible, and
the registration level domain chop is real hard to do with some tlds.

The absolute death of this proposal is, tho, that it puts the abuse
reporting address under the control of the spammer and becomes a DDOS
weapon.

I could just see it - it gets implemented for tana.it, and the next
day's blast of 10 billion cutwail botnet spams uses "HELO tana.it".

Kaboom!!!

SPF's helo identity as a reporting target

Alessandro Vesely — 2012-05-12T07:59:55

This probably belongs to ASRG, not only because MARF has finished, but
also because a *Taxonomy of reporting targets* should be hosted
somewhere, and I'm unable to think of a better place than this list's
wiki.

Opinions?

-------- Original Message --------
From: vesely< at >tana.it
Date: Tue, 08 May 2012 12:56:10 +0200
To: marf< at >ietf.org
Subject: SPF's helo identity as a reporting target

Hi all,

someone on the spf-discuss list noted that the smtp.helo is often of a
different type than the domains usually branded in smtp.mailfrom,
header.from, and dkim.d.  That's because it seems to be quite common
to outsource mail relaying as well as MX services.  This situation
characterizes relaying services as third parties that might manage
complaints and/or enforce policies, much like ESPs and ISPs.

MARF-AS generically allows any "domain that has been verified by the
[relevant] authentication mechanism", as well as "Abuse addresses in
WHOIS records of the IP address".

Would it be feasible to correlate auth methods' prop

Call for Nominations: Applied Networking Research Prize 2012

Eggert, Lars — 2012-04-10T09:39:25

                       CALL FOR NOMINATIONS:
         
            APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2012
               
                       http://irtf.org/anrp

***    Submit nominations for the 2012 award period of the        ***
***   Applied Networking Research Prize until May 13, 2012!       ***


The Applied Networking Research Prize (ANRP) is awarded for recent
results in applied networking research that are relevant for
transitioning into shipping Internet products and related
standardization efforts. Researchers with relevant, recently
published results are encouraged to apply for this prize, which will
offer them the opportunity to present and discuss their work with
the engineers, network operators, policy makers and scientists that
participate in the Internet Engineering Task Force (IETF) and its
research arm, the Internet Research Task Force (IRTF).

The goal of the Applied Networking Research Prize is to recognize
the best new ideas in networking, and bring them to the IETF and
IRT

[irsg] IRTF IPR Disclosure Rules (fwd)

John R. Levine — 2012-02-17T00:36:32

I don't recall IPR issues ever coming up in the ASRG, but in case they do, 
here is our clarified IPR policy.

Please note the parts about what you are required to disclose.

R's,
John

---------- Forwarded message ----------
Date: Thu, 16 Feb 2012 18:36:35
From: "Eggert, Lars" <lars< at >netapp.com>
Reply-To: "irtf-discuss< at >irtf.org" <irtf-discuss< at >irtf.org>
Subject: [irsg] IRTF IPR Disclosure Rules

Until now, the IRTF didn't have a clearly formulated statement of how IPR is handled by the organization. For the last year, the IRSG has been discussing this topic with the IETF's legal counsel and other community members with a deep understanding of the issues.

The result of this discussion is a short statement describing the IRTF's IPR disclosure rules, which you can find below as well as online at http://irtf.org/ipr. The short version is: the IRTF follows the IETF's IPR disclosure rules. Because researchers participating in the IRTF may not be very familiar with the IETF's rules, the IRTF IPR disclosure rules de

VB2012, Dallas: Call for papers

Martijn Grooten — 2012-02-08T15:30:32

See below. Submissions deadline is in just over a month from now.

Martijn.

Virus Bulletin is seeking submissions from those wishing to present
papers at VB2012, the 22nd Virus Bulletin International Conference,
which will take place 26-28 September 2012 at the Dallas Fairmont
hotel, Dallas, TX, USA.

The conference will include a programme of 30-minute presentations
running in two concurrent streams: Technical and Corporate.
Submissions are invited on all subjects relevant to anti-malware and
anti-spam. In particular, VB welcomes the submission of papers that
will provide delegates with ideas, advice and/or practical techniques,
and encourages presentations that include practical demonstrations of
techniques or new technologies.

Abstracts should be submitted via the online abstract submission
system at http://www.virusbtn.com/conference/abstracts/ and must be
submitted no later than FRIDAY 9th MARCH 2012.

Further details of the paper submission and selection process,
including a list of suggested topics

Re: RFC 6471 and "listing the Internet" as a punishment

Douglas Otis — 2012-01-31T21:50:01

Dear Dave,

When DNS transactions attempt to include all possible choices, necessary 
transactions are at a greater risk of being queued, rather than being 
ready in advance.  Chrome offers a switch setting to disable this 
behavior that may actually result in reduced performance.

Regards,
Doug Otis