Subject: Re: [Asrg] 6. Proposals: MTA MARK vs port 25 filtering?

From: Brett Watson <[email-masked]>
Date: Sun, 14 Dec 2003 15:48:47 +1100

A touchy issue, this. Should we consider it Best Current Practice to filter 
outgoing port 25 on "residential" (or similarly classified) access points? 
Should we consider it BCP to filter outgoing port 25 on pretty much all 
access points unless other arrangements are explicitly made?

Our contributor named "Mark" has been harping on the "presumption of 
innocence" principle, but it's precisely the viability of that principle 
that's in question here. There is a certain quantity of spam which exists by 
abusing the "presumption of innocence", so called. It's a badly 
emotionally-laden term, since to advocate the converse is to advocate 
"presumption of guilt", and you may as well advocate the strangulation of 
small furry animals and children while you're about it. Rather than 
"presumption of guilt", we should have "explicitly negotiated access". We 
could recommend that port 25 be available (in some cases) only when 
explicitly arranged, not on the basis of prior "guilt" or "innocence", but 
purely to make accountability explicit.

Personally, I reject outright the idea that filtering access points on port 25 
has a troublesome impact on mail connectivity for the do-it-yourself crowd, 
myself included. If you don't trust your ISP to get it right with regards to 
their mail server, it is now ridiculously cheap to get your own virtual 
server hosted somewhere and continue to do it yourself without your mail 
server hanging off your ISP's access point. Such virtual hosts require 
expertise to configure, but have unfettered access. In my view, people who 
are still harping on this point need to readjust to the new environment -- 
keep up with the times. I have seen virtual servers available for US$15 per 
month, which is a fraction of what I pay for my broadband access (in 
Australia).

On the other hand, malware ("viruses", "worms", "trojans", etc.) which abuses 
the openness of port 25 is rife. This is an attack vector that bears serious 
consideration. Similarly, "presumption of innocence" falls down for any 
dynamically allocated IP address, since there is no permanent identity 
associated with the IP. If we work on the "presumption of innocence" 
principle here, then the abusers get free reign for a short while, then 
tarnish the reputation of all users equally. It simply doesn't work. One 
possible suggestion for a BCP is to filter outgoing port 25 for all 
dynamically allocated IPs.

Taking the converse view, one could question the effectiveness of port 25 
filtering as a whole, relative to its intrusive nature. There is no escaping 
the fact that port blocking is intrusive, and it causes problems of its own. 
Does it provide a net improvement, or does it merely change the balance of 
problems?

Intrusive filtering is NOT the only option. We also have the option to place 
information about the IP out of band, as per one of the various DNS options. 
This does not change the argument about "presumption of innocence" versus 
"explicitly negotiated access" -- it only changes the mechanism by which 
filtering is taking place, and the party that elects to do the filtering. 
Where information about the trustworthiness of an IP is placed in the DNS, 
the mail recipient becomes the one to make decisions: a non-intrusive form of 
filtering which can, even so, produce similar results.

With careful semantics, we may even be able to produce a DNS-based solution 
which allows do-it-yourselfers to continue to operate their own mail servers, 
with limited scope for nuisance to others. An ISP could use in-addr.arpa PTR 
records to indicate "residential" or "dynamic" status for IP addresses (with 
the connotation that they are not well placed to prevent mail abuse from 
those sources). A person operating their own domain could override this 
rating by explicitly marking their own mail domain as operating from a given 
IP through their own domain records. A recipient can then decide whether to 
trust that sender's domain or not, based on his own assessment of risk.

So, having rambled about it for a bit, I conclude that port filtering is a 
tool worth considering in certain cases, and I dismiss the "presumption of 
innocence" argument as being both emotionally overcharged and no longer 
viable. Even so, it seems to me that the non-intrusive DNS-based options can 
more closely achieve the goal of recipient-oriented decisionmaking, and are 
less likely to cause unintended problems with connectivity generally. Let the 
recipients make up their own minds about whether they trust a sender or not: 
just give them information on which to base their decision.

Regards,
TFBW

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Philip Miller <[email-masked]>
Date: Sun, 14 Dec 2003 01:33:24 -0500

> access points unless other arrangements are explicitly made?

It is indeed a touchy issue. Since there's no consensus in the group, we 
should refrain from making recommendations until enough of us agree on 
something solid with a clear rationale.

> purely to make accountability explicit.

"Explicitly negotiated access" sounds really nice in theory, but it doesn't 
work for anyone who is limited to using a mass-market ISP. Comcast, my 
provider, has no interest in talking to customers, they have an interest in 
getting as much money out of us as possible. This "explicitly negotiated 
access" would mean they tack on some absurd monthly fee for 'administrative 
costs'.

> month, which is a fraction of what I pay for my broadband access (in 

I don't trust my ISP to get it right with regard to their mail server. They 
have some large number of MTAs which make outbound connections, and 1 or 2 
of them are blacklisted. Because of stupid policies enforced by other 
providers (AOL), I already cannot connect out directly, so I am forced to 
forward my mail through smtp.comcast.net. This means I have a choice between 
not reaching certain ASRG members whose servers use RBL or not reaching 
friends and family on AOL. I'm not going to reconfigure a mailserver used by 
multiple people every time I want to send a message to AOL or ASRG.
About virtual hosts: I am a student. I am a minor. I do not have ready 
access to a credit card to pay for such service. Whatever I can't get for 
free online, I can't get at a "ridiculously cheap" cost. I happen to have 
broadband access, and I run a server of my own, for utility and education. 
If I were forcibly prevented from using it, I would not be happy, and I'm 
sure many others are in a situation similar to this.

> dynamically allocated IPs.

The problem here is that there's no incentive for ISPs to cooperate. They 
will piss of those of us who care, and the people who are unable to spread 
digital contagion because of a block won't notice, except that they may have 
to pay more for ISPs to manage their new burden.

My point is, you're being equally idealistic in assuming that consumer, 
residential ISPs will actually serve their customers.

> just give them information on which to base their decision.

OK, I agree with this conclusion. I don't think there's anyone in this group 
who'd argue with the last sentence of that. Unfortunately, we, as a group, 
seem to be getting hung up on certain issues which are preventing us from 
moving forward on various proposals that need to maintain their momentum.

The LMAP discussion document needs cohesive review and editing, preferably 
before we publish as and Internet Draft. IDs are nice for some things, but 
it's easier if we make all of the changes we feel necessary before first 
official publication.

I haven't looked the closely at MTA Mark, but I think these two proposals 
are complementary, and should be revised to reflect that. I'm not sure if it 
does, but MTA Mark should probably not recommend outright rejection of 
messages in the face of information stating that a given IP should not be 
sending mail.

I've said my peace,
Philip Miller

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 14 Dec 2003 08:20:04 -0500 (EST)

> sure many others are in a situation similar to this.

It is important that "consent" include "consent of the sending AS"
expressed somehow. It could be lifting a block on port 25, or some
mechanism enforced only at the receipient end. But anything suggesting
that the origin AS should not have to provide consent for sending to port
25 is to create a right to spam which will be exceedingly difficult to
counter.

The current situation is that very few ISP even bother to block owned
machines. Surely that can't be BCP. BCP must be to forward port 25 packets
only for customers who have asked for such service. This is necessary to
protect address blocks (other customers) from loss of service.

Should Comcast enforce a block on port 25, and charge unreasonably for
unblocking it, then users of Comcast should explore using other MTAs. I
notice that smtp.com is already in the business of providing smtp relays,
and should a large operator like Comcast create a larger need, there would
no doubt be other players.

As a practical matter, indivduals using sendmail can use the mailertable
feature to direct messages directly to the remote MTA, but fall back to
a specified relay MTA should their access to the remote MTA be blocked
(for example, by receivers that reject mail apparent dial-up lines). 

Daniel Feenberg

---

From: Philip Miller <[email-masked]>
Date: Sun, 14 Dec 2003 11:02:53 -0500

> protect address blocks (other customers) from loss of service.

BCP would be carefully monitoring their network, and blocking any customers 
whose traffic signatures indicate that they've been '0wned' or infected. 
Failing that, it would be perfectly fine for them to block all potentially 
harmful traffic and allow it out upon customer request and possible 
acceptance of accountability.
However, they will do neither, because to do so would not be compatible with 
their business model. It costs them money to do anything more than block 
SMTP out universally or mark it all in DUL/MTA-Mark/whatever, and they don't 
want to spend that money. Most consumer ISPs are the same way, and some of 
us don't have an alternative.

> no doubt be other players.

How would an smtp.com relay help me if port 25 were blocked? My MUA wouldn't 
be able to connect to it either, unless they use SUBMIT, which is still 
exceedingly rare.

> (for example, by receivers that reject mail apparent dial-up lines). 

This is not unique to sendmail. As I said earlier, I run postfix, and all of 
my outgoing mail is relayed through smtp.comcast.net. However, If we were to 
push LMAP, I certainly would NOT want to authorize smtp.comcast.net to send 
for zemos.net, because that would allow any comcast customer to send as 
zemos.net, a very undesireable idea.
These proposals go hand in hand, but there are some kinks to work out.

Philip Miller

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Sun, 14 Dec 2003 11:10:30 -0500

> [Long and reasonable argument for blocking port 25]

"Yes", but "no".  :-)

For a strictly technical reason, mind you.  If port 25 becomes predominantly
filtered, email is slimply going to shift ports.  We will see an increase of
proxies over port 80 (most likely), and the corresponding abuse.

For that matter, I've figured out a trivial way of circumventing any such
measure to deliver spam; though I am loathe to discuss it here given that I
am fairly certain our adversaries read this list religiously.

I am convinced any solution against spam lie in separating the good email
from the bad, not in trying to prevent garbage from being inserted in the
system in the first place (though you obviously want to choke it as soon as
possible to reduce cost).

Perhaps a better direction to look in is not to prevent port 25 access
without prior arrangement but to prevent mass mailings without such
arrangements (however we choose to define this).  Throttling and refusing to
send email to more than a few destinations come to mind, asking legitimate
mailing lists to authenticate with a willing mail relay is not unreasonable
and doesn't prevent the general end to end philosophy.

I wouldn't mind if the ISP where my colo box lives refused to let me send
more than n mail per hour, say, unless I had a specific arrangement
otherwise.

I don't think it's realistic to try to prevent one-to-one spam, but
one-to-many mailings are easier to detect, and easier to control.

-- Marc

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 14 Dec 2003 11:09:37 -0500 (EST)

> be able to connect to it either, unless they use SUBMIT, which is still 

They accept mail via a different port. It isn't that clever, anyone could
have thought of it.They have other means of not becoming an open relay. I
don't mean to bring them up as the solution to Miller's problem, just to
point out that should his problem become widespread, solutions will become
widely available, and problably in multiple forms. MSA submit is another,
should MUAs become willing to give it first class support. But it isn't
the only possibility.

Daniel Feenberg

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 14 Dec 2003 11:13:03 -0500 (EST)

> proxies over port 80 (most likely), and the corresponding abuse.

This I don't understand. I don't run an MTA at port 80, so I don't receive
any spam via that port. Nor does anyone else I know, nor can I conceive of
any reason I might start doing so. 

Perhaps you are confused by lax terminology. When anti-spammers speak of
filtering port 25, they mean packets destined to port 25 on the remote
system. That is the only port that accepts mail from strangers on most
systems. 

Daniel Feenberg

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 15 Dec 2003 11:46:56 -0500

> it's easier if we make all of the changes we feel necessary before first 

  Patches?

  I've got a number of messages saved in a folder, and am planning to
update the document again before the end of the year.

  Alan DeKok.

---

From: Philip Miller <[email-masked]>
Date: Mon, 15 Dec 2003 17:57:04 -0500

> update the document again before the end of the year.

Well, here's one more. I'm not sure what to do about the organization, and I 
don't know how or where we would address the relevance of SMTP AUTH.

About the organization:
I don't think we should have 2 complete sections dedicated to
addressing, point by point, the specific requirements dreamt up by this
group. They should certainly all be addressed within the body of this
document, or in the protocol description. Basically, I think the best
way to address the myriad concerns is to integrate them in the
rationales for normative sections. I don't think we should end up with 2
separate documents when we're done, one describing the protocol(s) and
one defending it. This is not the norm from what I've seen in the RFCs, 
assuming we intend to eventually publish this as an RFC. If there is a 
precedent, point me to it and I'll stand corrected, but most things seem to 
be completely integrated.

About Section 2.1.2  "Why prevent domain forgery, instead of end-user
forgery?":
End-user authentication definitely has some bearing on the workings of
LMAP. If some major mail-originating domain implemented LMAP, but made
no provision to prevent transmission of spam or forged messages through the 
authorized servers, what good has it done? Worst case, you could have 
LMAP-listed open relays.
We should definitely at least recommend the use of SMTP AUTH within domains 
in tandem with LMAP.

--
Philip Miller

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 15 Dec 2003 20:03:50 -0500

Philip Miller wrote:
>>> The LMAP discussion document needs cohesive review and editing, 
>>> preferably before we publish as and Internet Draft. IDs are nice for 
>>> some things, but it's easier if we make all of the changes we feel 
>>> necessary before first official publication.
>>
>>
>>   Patches?
>>
> Well, here's one more. I'm not sure what to do about the organization, 
> and I don't know how or where we would address the relevance of SMTP AUTH.
> 
> About the organization:
> precedent, point me to it and I'll stand corrected, but most things seem 
> to be completely integrated.
> 

As a research group we are expected to concentrate on discussing the 
proposal itself, and leave the implementation to the IETF. Also, 
responding to requirements point by point has been an approach taken by 
some of the other RGs and WGs.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"All that is gold does not glitter" (LOTR)
-------

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 15 Dec 2003 21:59:19 -0500

My only input with this would be to be aware that ESMTP AUTH is typically
also used to open routing access in addressing the dynamic IP roaming user.
It also enforces a non-null address, and in our case, optionally enforces or
restricts the return path domain provided.

In other words, ESMTP AUTH trumps all.   LMAP or no LMAP,  it opens routing
to users.

Note, there are 3 basic ways email (smtp/pop3) server vendors open access to
relaying/routing:

1)  The traditional IP relay tables
2)  ESMTP AUTH
3)  POP3 BEFORE SMTP

The latter often used by ISP to reduce the user support issues created by
the first two.  The first doesn't help the roaming user problem and the
second require ESMTP ready end-user software and additional ISP setup
instructions for the user.

However, POP3 BEFORE SMTP is based on the premise that most end-user mail
software POP3 into a system before SENDING any mail.   For example, you will
see this option in Outlook as

            (*)  Pick up mail first before sending mail

or something like that as alternative option to ( ) Server requires login to
send mail.

-- Hector

---

From: Philip Miller <[email-masked]>
Date: Mon, 15 Dec 2003 22:19:44 -0500

> In other words, ESMTP AUTH trumps all.   LMAP or no LMAP,  it opens routing

Yes, except that AUTH does nothing on the public internet if spammers can 
originate messages from someone without authenticating as that someone. 
These are complementary. LMAP makes it so that mail from a given address can 
only come from a limited set of servers, and AUTH lets those servers ensure 
that the address on mail they're transmitting is not forged.
AUTH is only useful within an organization, not across the public internet. 
You can't expect to connect to one of AOL's MX servers, AUTH as somebody 
(how would you if you're not an AOL subscriber?), and have that server 
accept your mail. Note that a roaming user connecting to the home server is 
'within an organization'.

> instructions for the user.

Every major MUA has supported AUTH for a long time, AFAIK. Outlook, Outlook 
Express, Netscape (in all variants since at least 4), Eudora, etc. The real 
cost is user implementation. It imposes a massive support cost on any 
organization that does not control the machines used to send mail, such as 
most commercial ISPs. Note, however, that this does not affect AOL, because 
users must login before they can originate email. They have a semantically 
more sensible equivalent to POP-before-SMTP.

> or something like that as alternative option to ( ) Server requires login to

POP-before-SMTP was an ugly hack to make up for shortcomings in existing 
software. Unfortunately, it stuck. It's clearly obsoleted by SMTP AUTH, but 
there's no compelling reason for users to switch, and thus ISPs have to deal 
with the inertia of their users. I think we're going to have to live with it 
for a long time.
However, that does not change the fact that LMAP and user authentication 
target 2 complentary but separate problems: domain forgery, which prevents 
holding anyone accountable, and user forgery, which is a nuisance best dealt 
with by the organization that hosts the user's address, since they are 
uniquely able to authenticate the user.

Philip Miller

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 15 Dec 2003 23:08:44 -0500

----- Original Message ----- 
From: "Philip Miller" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, December 15, 2003 10:19 PM
Subject: Re: [Asrg] 6. Proposals: MTA MARK vs port 25 filtering?

> with the inertia of their users. I think we're going to have to live with
it

I was resistance to the idea myself until ISPs indicated their side of the
story.  Easy end-user signs up with little or no instructions.  They were
right.  Once we added it,  it is now rare for us to be telling our customers
they need to setup their mail client for SMTP authentication.   Look at how
the software is written for the end user.  The only easy setup is for POP3
login.  SMTP authentication requires extra steps and instructions.  It is
not obvious.

> uniquely able to authenticate the user.

I agree.  My point is only that most systems with ESMTP AUTH use it to trump
most (if not all) other restrictions, which is mainly routing.  So as long
as you can login,  it doesn't matter what machine you connect from or what
address you use for the return path.  In our case, however, we have
restrictions for the return path in AUTH mode.

The question is how will LMAP address systems like AOL who are now
automatically blocking dynamic IP machines at the connection level.

Does LMAP address IP ranges?

Are we ready to say that dynamic IP senders are no longer allowed?

The way I see it from an implementation standpoint, LMAP can only be used
for a "accept" logic.  It can't be used to reject for lack of a LMAP based
information.

        LMAP  AUTH
         0               0         Low trust
         1               0         X trust
          0              1         Y trust
          1               1        Z trust

Z is great,  Y is still better than X.   With just X,  we are still
scratching our heads which is the point you are making I believe.   What I
am saying, you don't need X if you have Y and I sincerely doubt systems are
going to remove this logic to programmatically require X before you can have
Y.    As long as you have Y (AUTH), you are in.   In short, Trust Z  >=
Trust Y.    With no X,   Z=Y.

-- Hector

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 16 Dec 2003 13:41:14 -0500

> don't know how or where we would address the relevance of SMTP AUTH.

  I don't think SMTP AUTH is relevant.  It's intended to be user
authentication, not MTA authentication.

  We could extend SMTP AUTH to do MTA authentication, but it would
then end up looking like LMAP.

> group.

  They're not.  They addressing two documents.  When/if the documents
get merged, the sections in the LMAP discussion paper can get merged.

> authorized servers, what good has it done? Worst case, you could have 

  Nothing can ever prevent the abuse of valid user accounts, or of
invalid MTA configurations.

> We should definitely at least recommend the use of SMTP AUTH within domains 

  That's my opinion, too.

  I don't understand why it's considered reasonable to have every MTA
on the planet authenticate everyone else's users.  Systems which have
such requirements in their design are fundamentally flawed.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 16 Dec 2003 13:45:32 -0500

> Does LMAP address IP ranges?

  Yes.  See the various drafts for different syntactic ways of
implementing this.

> Are we ready to say that dynamic IP senders are no longer allowed?

  That's up to the domain they claim to be associated with.  The
recipient MTA doesn't know, or care, that the user has a dynamic IP.

> for a "accept" logic.  It can't be used to reject for lack of a LMAP based

  That's pretty much what the document says.

> am saying, you don't need X if you have Y 

  I don't see why.

  SMTP AUTH is a user to sending MTA authentication protocol.  LMAP is
an domain to MTA authorization protocol.  I don't see why using one
would negate the need for the other.

  Alan DeKok.

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 16 Dec 2003 14:03:28 -0500

Hi Alan,

Thanks Alan, I'll trying to keep up.  Maybe you can help summarize it here:

Who has LMAP deployed currently to evaluate its effectiveness?

What is the recommended refusal methods for a LMAP rejection?

Does LMAP offer a fallback?

Does LMAP rejection pre-empt an ESMTP AUTH?

Does LMAP even allow for ESMTP AUTH to be reached?

You have to just put yourself in the position of the engineer that will be
programming this and passing it on to customers.    Right now ESMTP AUTH
trumps all restrictions or issues that deal with SPAM or dynamic IP or
whatever.   Where and how LMAP would fit in with everything else is what I
am trying to see.   Unless I am seeing it wrong, I agree with Phillip,  the
domain check itself is insufficient.

-- Hector

---

From: Mark Baugher <[email-masked]>
Date: Tue, 16 Dec 2003 11:21:59 -0800

At 10:41 AM 12/16/2003, Alan DeKok wrote:
> and I

I believe SMTP TLS is intended for MTA authentication.

Mark

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 16 Dec 2003 15:01:32 -0500

> I believe SMTP TLS is intended for MTA authentication.

  Yes, it also solves the security/privacy issue.  But it's
authentication + security, not just authentication.  And I don't think
many MTA's allow STARTTLS with cipher "none".

  Section 5.1 of RFC 2487 says:

---
   The decision of whether or not to believe the authenticity of the
   other party in a TLS negotiation is a local matter. However, some
   general rules for the decisions are:

    - A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.
    - A publicly-referenced  SMTP server would probably want to accept
      any certificate from an SMTP client, and would possibly want to
      put distinguishing information about the certificate in the
      Received header of messages that were relayed or submitted from
      the client.
---

  The second option becomes more useful if the senders certificate is
in DNS somewhere, or is signed with a well-known public key, also
visible in DNS.

  Section 7 "Security Considerations" is also useful:

---
   It should be noted that SMTP is not an end-to-end mechanism. Thus,
   if an SMTP client/server pair decide to add TLS privacy, they are
   not securing the transport from the originating mail user agent to
   the recipient.  Further, because delivery of a single piece of mail
   may go between more than two SMTP servers, adding TLS privacy to
   one pair of servers does not mean that the entire SMTP chain has
   been made private. Further, just because an SMTP server can
   authenticate an SMTP client, it does not mean that the mail from
   the SMTP client was authenticated by the SMTP client when the
   client received it.
---

  Other methods can potentially extend the authentication of the
message beyond the per-hop limit of STARTTLS.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 16 Dec 2003 15:14:20 -0500

> Who has LMAP deployed currently to evaluate its effectiveness?

  Read the related drafts.  Many have been implemented.

> What is the recommended refusal methods for a LMAP rejection?

  I'm not sure what you mean by that.

> Does LMAP offer a fallback?

  To what?  Read the discussion paper, and the various protocol
drafts, they discuss this topic.

> Does LMAP even allow for ESMTP AUTH to be reached?

  Read the discussion paper and the drafts.  They make it clear that
those questions are orthogonal to LMAP, and are thus local site
configuration issues.  i.e. They're irrelevant to LMAP.

> am trying to see.

  Read the documents.

  Alan DeKok.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Dec 2003 15:55:25 -0500

> many MTA's allow STARTTLS with cipher "none".
[..]
> message beyond the per-hop limit of STARTTLS.

With LMAP, authentication is done to the originating domain, as opposed 
to per-hop basis.

However, it seems to me that in cases where someone outsources their 
email delivery, there will be significant administrative issues since 
the owner of the domain will have to list all possible outbound servers 
of the outsourcer in LMAP records. And anytime this information changes, 
the DNS records need to be updated.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Be liberal in what you accept, and conservative in what you send" (Jon 
Postel)
-------

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 16 Dec 2003 16:57:39 -0500

> With LMAP, authentication is done to the originating domain, as opposed 

  That's the phrasing I was looking for.  Thanks.  It's been a long day.

> the DNS records need to be updated.

  One word: delegation.

  If *all* of their mail is outsourced, then the LMAP records can be
delegated to the domain which performs the delivery.

  If some of the mail is outsourced, then this will be discovered
because the outsourced machine will probably do:

  EHLO outsource-machine.example.com
  MAIL FROM: [email-masked]
  
  The LMAP system can check:

  1) reverse-ip._lmap_.example.net
  2) reverse-ip.example.com._lmap_.example.net

  The first question asks: "is this IP authorized to send messages as
example.net?"  If the answer is no, the second question is asked,
which is:

  "Is this IP, which claims to be within example.com, allowed to send
messages as example.net?"  example.net can then do something like:

  example.com._lmap_.example.net      IN PTR _lmap_.example.com

  That should be easy to do, and should simplify a lot of the
delegation issues.

  Alan DeKok.

---

From: Claus Assmann <[email-masked]>
Date: Tue, 16 Dec 2003 14:50:58 -0800

> authentication, not MTA authentication.

What in the RFC prevents it from being used for MTA authentication?

>   We could extend SMTP AUTH to do MTA authentication, but it would

What should an extension look like?

> then end up looking like LMAP.

Please be more specific.

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 17 Dec 2003 00:00:48 +0100

> system. That is the only port that accepts mail from strangers on most

If you start to block port 25 outgoing people will start to make wide
use of SRV records, because a lot of receiving MTAs will /want/ to 
talk to users behind port 25 blocked networks.
With SRV records you don't need well-known ports any longer, but you
specify the port your SMTP speaking MTA is listening on in the SRV
record itself.
Port 25 blocking rendered useless.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 17 Dec 2003 01:02:56 +0100

> purely to make accountability explicit.

Folx, I don't get it ;-)

If you are running a mailserver (MTA) you are free to block every host
that you wish. Our mailserver (not for our customers) will not talk to
about 150 millions of IP addresses on the Internet. This list grows with
a rate of about 250000 a day. This is my decision as the receiver and
every receiver is currently free to make that decision.

So, why do you want to have any transport agents (aka ISPs) install
filters and remove your ability to make that decision on your own?
If it's blocked by the transport agency you have no way to reverse that,
no matter how your decision might be.

If the port is blocked you get no information on why it is blocked. So
the theoretical sender is still unknown to you. Maybe the ISP is having
an issue of some sort and is now blocking the sender with an attempt to
put pressure on him.
Port 25 is interrupting services and not speading policy or sender
information.

	\Maex

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Dec 2003 19:25:23 -0500

> Port 25 is interrupting services and not speading policy or sender

It seems to me that there are both sides have presented multiple 
arguments, and no agreement is in sight. There are two questions being 
asked in this and related threads:
1. Is MTA MARK a useful enough proposal to be pursued further IN 
COMBINATION with other anti-spam tools and techniques (including port 
filtering)?
2. Is port filtering, on port 25 especially, should be something that is 
going to be recommended by the ASRG?

Based on the discussions back and forth, it seems to me that the answer 
to the first question is 'YES', and the second question 'NO'. MTA MARK 
provides enough useful benefits for the ones that can use it, in order 
to continue researching it. Port blocking on the other hand seems 
controversial enough, that it should be something best left to each ISP 
to decide. Instead we should recommend that ISPs have a strict AUP and 
actually enforce it.

Yakov

-------

---

From: Philip Miller <[email-masked]>
Date: Tue, 16 Dec 2003 20:23:50 -0500

Hector Santos wrote:
> Philip Miller wrote:
> 
>> POP-before-SMTP was an ugly hack to make up for shortcomings in
>> existing software. Unfortunately, it stuck. It's clearly obsoleted by
>> SMTP AUTH, but there's no compelling reason for users to switch, and
>> thus ISPs have to deal with the inertia of their users. I think we're
>> going to have to live with it for a long time.
> 

This is a problem of the initial design of SMTP. Initially, SMTP didn't
require authentication, so no one designed it in as an integral part of
client software. POP clearly required authentication, so it was built in,
and clients were forced to include it.
The intelligent thing for a mail client to do is automatically attempt to
AUTH (if it's offered, obviously) and then fall back on POP-before-SMTP.
This is reasonable behavior for the average case of a user who sends and
receives mail through the same ISP account. Users who have a more
complicated configuration would be perfectly able to change this, as it
should be no more than a checkbox. This is probably something we should take
account of in a BCP for mail client authors.

>> However, that does not change the fact that LMAP and user
>> authentication target 2 complentary but separate problems: domain
>> forgery, which prevents holding anyone accountable, and user forgery,
>> which is a nuisance best dealt with by the organization that hosts the
>> user's address, since they are uniquely able to authenticate the user.
> 

OK, I misunderstood you the first time. That's exactly how I have my MTA set up.

> automatically blocking dynamic IP machines at the connection level.

Either their policies will change to accept mail presenting valid LMAP
credentials despite their 'undesireable' IP address, or they won't. AOL has
been off in its own world for a long time, and we're not going to change
that. We should make LMAP as attractive as possible by playing up the
newly-available accountability, maybe pushing for legislation holding
LMAP-authorized MTA administrators responsible for the actions of those servers.

> Does LMAP address IP ranges?

No. It addresses whether a given IP can send mail as a given domain, and
nothing else. If you meant "can a range of IP addresses be listed for a
domain?", I'm not sure, one of us would have to check the current SPF draft.

> Are we ready to say that dynamic IP senders are no longer allowed?

Most of us would say no. AOL management says yes. We've seen that this was
not the decision of their system administrators. Brad Knowles, who was in
charge of their Internet mail gateway system for years, fought this policy
and failed.

> for a "accept" logic.  It can't be used to reject for lack of a LMAP based

Eventually, the intent is that it would. Mail from a domain that doesn't
publish LMAP information could be treated as mail from an open relay.
There's no accountability at all beyond having the IP address the connection
was made from, which is exactly as much information as we have about
open-relayed mail now.

> Y.    As long as you have Y (AUTH), you are in.   In short, Trust Z  >=

OK, you point is clearer now. However LMAP is implemented in recipient MTAs, 
authors would have to be sure not to preclude AUTHing.

Philip Miller

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 17 Dec 2003 14:19:46 -0500

> COMBINATION with other anti-spam tools and techniques (including port 

  Yes.

> going to be recommended by the ASRG?

  No.

  It's something we should describe as an option.  We should describe
it's benefits, and it's limitations.  We should put a big "use at your
own risk" warning label on it.  We should also say that ISP's MUST
tell their users that they do this, to enable informed consent.

  For ISP's who know (AUP, etc.) that certain IP ranges will never
have an MTA sending mail, filtering outbound port 25 may be
beneficial.  For other situations, it may cause more problems than it
solves.

> Port blocking on the other hand seems controversial enough, that it
> should be something best left to each ISP to decide. Instead we
> should recommend that ISPs have a strict AUP and actually enforce
> it.

  I would like to enforce the ISP's AUP, too.  The ISP should
therefore publish it in a manner in which I can parse: MTAMark, LMAP,
etc.  My problem with these "solutions" is that they're post-facto,
and still permit the AUP to be violated.  Blocking port 25 is
appealing, because it prevents AUP violations.  But it's a very
dangerous practice, from a number of perspectives.

  Alan DeKok.