Re: Transparent hijacking of SMTP submission...

[Christopher Morrow <morrowc.lists () gmail com>]

On Sat, Nov 29, 2014 at 10:27 PM, joel jaeggli <joelja () bogus com> wrote:
> On 11/29/14 6:32 PM, Christopher Morrow wrote:
> > On Sat, Nov 29, 2014 at 3:09 PM, John Levine <johnl () iecc com> wrote:
> > > In article <CAL9jLaY1q_RBkyB6kczKZUiFR5b1r3kuVz8WivWR0Rjj_oaGTg () mail gmail com> you write:
> > > > backing up a bit in the conversation, perhaps this is just in some
> > > > regions of comcastlandia? I don't see this in Northern Virginia...
> > >
> > > I don't see it in New Jersey, either.
> > >
> > > Is this a direct connection, or a coffee shop sharing a cable connection or
> > > something like that?
> >
> > my test was a home consumer cable link, not business grade and not
> > shared (more than cable is).
>
> The phenomena I reported was observed on a consumer cable service (not
> my own). it is now no-longer in evidence with that same source ip. In
> answer an intermediate observation, the cpe and the devices on it are
> sufficiently well understood now to rule them out.

ah, phew.

> from the mail servers vantage point...
>
> Nov 27 xxxxx nagasaki sm-mta[5698]: NOQUEUE: tcpwrappers
> ((reverse).wa.comcast.net, (ip) ) rejection

super odd, and telling.

> given that the client gives up because it can't startssl and therefore
> won't attempt to auth.
>
> whereas a successful attempt with the same source ip is:
>
> Nov 26 xxxxx nagasaki sm-mta[397]: STARTTLS=server,
> relay=c-(reverse).wa.comcast.net [(ip)], version=TLSv1/SSLv3,
> verify=NOT, cipher=DHE-RSA-AES128-SHA, bits=128/128

perhaps comcast (technician) was trying to do the 'right thing' here
and mistook 'but someone is operating a mailserver that the trust' vs
'spammer' from the situation with TLS being 'a good thing' and 'please
do not subvert my tls, yo!'

glad to see this returned to expected flows.