Transparent hijacking of SMTP submission...

Sun Nov 30 03:27:06 UTC 2014

On 11/29/14 6:32 PM, Christopher Morrow wrote:
> On Sat, Nov 29, 2014 at 3:09 PM, John Levine <johnl at iecc.com> wrote:
>> In article <CAL9jLaY1q_RBkyB6kczKZUiFR5b1r3kuVz8WivWR0Rjj_oaGTg at 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.

from the mail servers vantage point...

Nov 27 xxxxx nagasaki sm-mta[5698]: NOQUEUE: tcpwrappers
((reverse).wa.comcast.net, (ip) ) rejection

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20141129/de363278/attachment.sig>