On Sun, 1 Jan 2012, James Smallacombe wrote:
I have been doing this for 16 years. It has always been SOP to provide
an offending email, with full headers to the complaint recipient, if not
in advance of such blacklisting, then at least upon request.
There are/have been a number of well respe
On Sun, 2012-01-01 at 21:03 -0500, James Smallacombe wrote:
> The IP address of our mail server was recently blacklisted by MSN/Hotmail.
> When I went through their steps for delisting, it was denied based on
> "reputation". AFAIK, we have not had a spam problem for several months.
> When we
The IP address of our mail server was recently blacklisted by MSN/Hotmail.
When I went through their steps for delisting, it was denied based on
"reputation". AFAIK, we have not had a spam problem for several months. When
we did it was due to a few accounts having been successfully phished.
Yes, I know; I'm on that list. John Smith decided to see if
reality matched theory -- always a good thing to do -- and asked
here.
Btw, it's not just "this time there is some support for it"; AH
was downgraded to "MAY" in RFC 4301 in 2005.
On Jan 1, 2012, at 8:56 PM, Jack Kohn wrote:
> The __
The __exact__ same discussion happening on IPsecME WG right now.
http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html
It seems there is yet another effort being made to "retire" AH so that
we have less # of options to deal with. This time there is some
support for it ..
Jack
On Mon,
On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
> John,
>
> Unlike AH, ESP in transport mode does not provide integrity and
> authentication for the entire IP packet. However, in Tunnel Mode, where the
> entire original IP packet is encapsulated with a new packet header added,
> ESP protection
John,
Unlike AH, ESP in transport mode does not provide integrity and authentication
for the entire IP packet. However, in Tunnel Mode, where the entire original
IP packet is encapsulated with a new packet header added, ESP protection is
afforded to the whole inner IP packet (including the
On Mon, Jan 2, 2012 at 6:27 AM, Chuck Anderson wrote:
> I'm using AH for OSPFv2 and OSPFv3 authentication. For OSPFv3, there
> is no other option than some kind of IPsec for authentication. I'm
> also using it for OSPFv2 so I don't have to maintain multiple
> authentication methods and keys for
I'm using AH for OSPFv2 and OSPFv3 authentication. For OSPFv3, there
is no other option than some kind of IPsec for authentication. I'm
also using it for OSPFv2 so I don't have to maintain multiple
authentication methods and keys for the different protocols.
It can be used to prevent NAT on an intermediate path, which can be useful
under certain circumstances. I have seen it in the wild, both in Internet and
private networking contexts.
David Barak
Hi Tom,
Thanks for the reply.
Why cant we use ESP/NULL for meeting the NIST requirement? Is there something
extra that AH offers here?
Regards,
John
From: TR Shaw
To: John Smith
Cc: "nanog@nanog.org"
Sent: Monday, 2 January 2012, 5:57
Subject: Re: Does
(Sigh) Here we go again.
AH is a liability and a baggage that we're carrying over our weary
shoulders. IMO we should have gotten rid of it long time back. There
have been enough emails on multiple forums over this and google is
probably your friend here. The only reason(s) we have AH is because
(i
On Jan 1, 2012, at 7:12 PM, John Smith wrote:
> Hi,
>
> I am trying to see if there are people who use AH specially since RFC 4301
> has a MAY for AH and a MUST for ESP-NULL. While operators may not care about
> a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all
> protoc
Hi,
I am trying to see if there are people who use AH specially since RFC 4301 has
a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY
or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols
that require IPsec for authentication implicitly have a
Ray Soucy wrote:
Well, it seems now you've also added the requirement that we also
dramatically re-write all software that makes use of networking.
Seemingly for the sake of never admitting that you can be wrong.
Thank you for failing to point out where I am wrong.
You seem to think that the
Alexander Harrowell wrote:
> Alternatively, you can work on the assumption that the WLAN
> is solely for nomadic use rather than true mobility, but a
> lot of devices will prefer the WLAN whenever possible.
>
> Thoughts/experiences?
It depends on applications.
If mobile devices act as clients t
Christian Esteve wrote:
> May be there is some light with Multipath TCP:
> http://www.ietf.org/proceedings/75/slides/mptcp-0.pdf
> http://datatracker.ietf.org/wg/mptcp/charter/
Not bad.
> If you can live without UDP and other issues discussed in this bizarre
> discussion...
UDP connection, if a
17 matches
Mail list logo
