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

From: Daniel Feenberg <[email-masked]>
Date: Fri, 16 Jan 2004 19:45:22 -0500 (EST)

On Wed, 17 Dec 2003, Markus Stumpf wrote:

> On Sun, Dec 14, 2003 at 11:13:03AM -0500, Daniel Feenberg wrote:
> > 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. 
> 
> 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.
> 

Useless is perhaps too strong a word. 

If some MTA operators wish to receive mail from blocked systems, that is
of course within their ability, and I don't think anyone wants to restrict
that. Most systems accepting mail on ports other than 25 use some form of
authentication. The problem solved by blocking outbound port 25 is that is
for ISPs that wish to reduce compliants about spam emmisions. Any system
receiving unauthenticated mail on another port, is unlikely to complain to
the source ISP.

Daniel Feenberg

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

---

From: John Levine <[email-masked]>
Date: 17 Jan 2004 02:44:46 -0000

>> specify the port your SMTP speaking MTA is listening on in the SRV

I don't know of anyone who has much interest in getting SMTP
connections from random PPP and DHCP users.  I know that to a very
close approximation, that mail is 100% spam and viruses.

On the other hand, I am quite happy for my users, all of whom use
other ISPs to connect to the net, to use SMTP AUTH to prove who they
are, and then send mail to anyone they want.  That's known as SUBMIT,
and the standard port is 587.  I should publish a few SRV records in
case anyone goes looking for them.

>> Port 25 blocking rendered useless.

Not at all, it does exactly what it's supposed to. It forces mail to
strangers to be passed through the ISP's MTA where there's some chance
of detecting spam on the way out.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
[email-masked], Village Trustee and Sewer Commissioner, http://iecc.com/johnl, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 18 Jan 2004 20:48:26 -0500

> close approximation, that mail is 100% spam and viruses.

  Few people disagree with you there.

  See the list archives for flame wars involving people who want to
*send* messages from random PPP accounts, and random addresses via
DHCP.  Also note that there are zero responses[1] to requests asking
"what's wrong with SUBMIT, or umpteen other submission methods".

  Alan DeKok.
[1] I don't count responses which amount to "I don't want to change my
behavior", or "SMTP on port 25 is the One True Way to deliver mail,
everything else is evil."

---

From: Philip Miller <[email-masked]>
Date: Sun, 18 Jan 2004 21:08:57 -0500

> everything else is evil."

Currently, I deliver mail from a cable-modem hosted MTA that also hosts the 
backup MX for a domain I share with some friends. I relay through 
smtp.comcast.net, so I'm not sure if you really count that. However, I have 
encountered systems that check each machine in the Received: headers against 
dialup/DHCP lists. Hell, on one occasion, smtp.comcast.net has been 
blacklisted, when if I could do direct delivery, my mail would have gotten 
through.
LMAP as an addition to the status quo would hurt me even more, because 
there's no possible way I could create acceptable LMAP entries for my domain 
unless recipients start accepting mail from dynamic addresses. SUBMIT is 
irrelevant here, because my server *is* the "real" one, the one that 
authenticates mail from my domain. So filtering mail from non-leased 
addresses is not just a matter of mail submission.
I'm quite willing to change my behaviour, if you can tell me how. I would be 
delighted to declare accountability for messages from my own server, if only 
to remove the need for my ISP's relay.

Philip Miller

---

From: John Levine <[email-masked]>
Date: 19 Jan 2004 03:48:48 -0000

>> DHCP.

BTDT, not our problem.  I'm sorry if they feel they're treated like
second class net citizens, but that's because they really are second
class net citizens.

> Currently, I deliver mail from a cable-modem hosted MTA that also
> hosts the backup MX for a domain I share with some friends. I relay
> through smtp.comcast.net, so I'm not sure if you really count that.

That's the normal setup for consumer broadband.  Comcast would mark
their SMTP relay as "mail:yes" since that's where the mail's supposed
to be sent to the rest of the world.

> However, I have encountered systems that check each machine in the
> Received: headers against dialup/DHCP lists.

Me too.  You can't stop people from being stupid, although I'd think
that they'd notice that they're throwing away all mail from all
consumer ISPs.  I suppose that might be their goal.

> I would be delighted to declare accountability for messages from my
> own server, if only to remove the need for my ISP's relay.

It depends whether you have a static or DHCP address.  If it's static,
you should be able to set the mark data for the range assigned to you
just like you should be able to set your own rDNS.  If not, you don't
get what you don't pay for.  I realize that many cable DHCP addresses
change only every six months, but it's still DHCP and your ISP can't
provide contact info by rwhois.  I also realize that the practical
issue of getting semi-sentient ISPs to provide a way for their static
IP customers to update their own rDNS is a problem.

Regards,

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 19 Jan 2004 10:07:19 +0000

>provide contact info by rwhois.  

I don't know, but what's to stop you doing SPF / some kind of dynamic DNS?

--

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 19 Jan 2004 13:09:03 -0500

John Levine <[email-masked]> wrote:
> just like you should be able to set your own rDNS.

  Ideally, LMAP should be more than a simple list of IP's permitted to
send spam.  We can populate reverse DNS with other pieces of
information, like:

  - reference: company "foo" says I'm not a spammer

  - permissions: IP bar is OK

  - policy: IP/mask is OK, so long as the message is signed with key "pgp"

  - pointer: go ask roaming.isp.example.com if it's OK.

  Many of the concerns about dynamic DNS and small domains can be
addressed with trivial additions to the protocol.  The fundamental
concept remains the same, though: publishing information as to how the
recipient can tell that certain messages were sent consentually.

> I also realize that the practical issue of getting semi-sentient
> ISPs to provide a way for their static IP customers to update their
> own rDNS is a problem.

  Which is why unlike MTA-MARK, LMAP uses RNDS rooted from domains,
and not in-addr.arpa

  Alan DeKok.

---

From: Philip Miller <[email-masked]>
Date: Mon, 19 Jan 2004 15:14:27 -0500

> recipient can tell that certain messages were sent consentually.

OK, so there are a few parties who could/should be 'consenting':
1. HELO Domain owner
2. MAIL FROM Domain owner
3. Machine owner
4. IP Address space owner
5. Connectivity provider

Although in most cases, some of these will be conflated, I can imagine cases 
in which each of these is an independent entity. The LMAP discussion 
document seems to apply it to 1 & 2 only.
There are 2 questions that arise:
How comprehensive do we want LMAP to be?
How will a typical receiver-side implementation enforce the stated policies, 
especially when they conflict?

Philip Miller