[7768] in Release_7.7_team
Re: Changing How MIT's VPN & Dial-Up Servers Handle Unauthenticated Email
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Tue May 22 10:57:17 2012
Message-Id: <201205221457.q4MEvEAp012469@outgoing.mit.edu>
To: Jonathan Reed <jdreed@MIT.EDU>
cc: Geoffrey Thomas <geofft@MIT.EDU>, Andrew Munchbach <amunch@MIT.EDU>,
"itss@mit.edu" <itss@MIT.EDU>,
"release-team@mit.edu" <release-team@MIT.EDU>
In-reply-to: <196578BF-4002-4ED3-BFCA-4CEE2940EEEF@mit.edu>
Date: Tue, 22 May 2012 10:57:13 -0400
From: Jonathon Weiss <jweiss@MIT.EDU>
I don't have specific knowledge of how the block would be preformed, but
I would expect the behavior to be the same as for off-campus hosts
today. I believe they are blocked by the firewall, which means the
expected behavior is hangign while trying to establish the connection
until a timeout occurs.
Assuming that is the case then yes, we'll want to make debathena-msmtp
clever enough not to even try the connection and just return a fast
error. I do hope to do that for the dialups, but I'm not sure when, and
I expect the code I wrote to never try an unauth'd connection, and not
to do a lookup on the IP address before deciding. That said, I'd love
it if someone else wrote the code and I didn't have to. :-)
I also don't have a hard answer regarding linerva, but Garry and I are
both of the opnion that it should be treated the same way as the
dialups, especially since we're still planning to move the name to the
dialups.
--
Jonathon
Jonathan Reed <jdreed@MIT.EDU> wrote:
> (dropping linerva, CC release-team)
>
> Do we know the details of how mail will be rejected? e.g. Will connections get rejected explicitly at the network level, or will they simply hang forever until they timeout, or will sendmail respond with a 5xx error? (the latter seems unlikely)
>
> We should ensure debathena-msmtp behaves nicely in general if on a VPN, though presumably Ops has considered this and will include it in their dialup customizations.
>
> -Jon
>
> Sent from my mobile device
>
> On May 18, 2012, at 12:48 PM, Geoffrey Thomas <geofft@MIT.EDU> wrote:
>
> > Okay, cool. Linerva is on a different network, so I'd assume not (and approximately everything else on 18.181 needs to send unauthenticated mail). Thanks for checking.
> >
> > --
> > Geoffrey Thomas
> > SIPB Linerva team
> > linerva@mit.edu
> >
> > On Fri, 18 May 2012, Andrew Munchbach wrote:
> >
> >> Hi Geoffrey,
> >>
> >> The dial-up servers are losing access to outgoing-legacy.mit.edu
> >> (mint-square, scrubbing-bubbles, etc.). I (perhaps incorrectly) assumed
> >> linux.mit.edu was included in this mix. I'll double-check with Server Ops
> >> on what impact this will (or will not) have on Linerva and get back to you.
> >>
> >> Best,
> >> Andrew
> >>
> >> On 5/18/12 1:16 PM, "Geoffrey Thomas" <geofft@MIT.EDU> wrote:
> >>
> >>> On Fri, 18 May 2012, Andrew Munchbach wrote:
> >>>
> >>>> * Users on the dial-up servers (ssh linux.mit.edu) that try to send
> >>>> unauthenticated email using the server outgoing-legacy.mit.edu.
> >>>
> >>> Hi Andrew,
> >>>
> >>> Given your mention of linux.mit.edu, I wanted to confirm whether Linerva
> >>> is included or not in this change. I guess it's not unreasonable to count
> >>> Linerva and athena.dialup as equivalent for these purposes, but we do
> >>> have
> >>> some changes we'll need to make so that e.g. cronjobs from root send
> >>> authenticated mail, and we may have different user assumptions than
> >>> athena.dialup has (notably, we allow logging in without delegating
> >>> credentials, and athena.dialup doesn't).
> >>>
> >>> While there's discussion of switching linux.mit.edu to point to
> >>> athena.dialup, I'm pretty sure that's not going to happen by the time of
> >>> this change. Then again, if this is just a typo, that would make things
> >>> easier for us. :)
> >>>
> >>> --
> >>> Geoffrey Thomas
> >>> SIPB Linerva team
> >>> linerva@mit.edu
> >>
> >>
