Subject: Does our passport need to be valid for 6 months to go to Prague?

From: Radia Perlman <[email-masked]>
Date: Sat, 17 Feb 2007 18:03:55 -0800

There are some countries that require not just a *valid* passport, but 
one which won't
expire for  6 months beyond when you visit a country. Is Prague in one 
of these countries (for US citizens)?
I've heard conflicting things.

If it does have the requirement (that a passport has to be valid for
6 months beyond the IETF meeting), it should probably be noted on the 
ietf page about the meeting. I couldn't
see any information about passport expiration -- just that we don't need 
a visa.

Does anyone know definitively?

Thanks,

Radia

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

---

From: Michael StJohns <[email-masked]>
Date: Sun, 18 Feb 2007 02:03:20 -0500

http://travel.state.gov/travel/cis_pa_tw/cis/cis_1099.html

3 months is the requirement.

At 09:03 PM 2/17/2007, Radia Perlman wrote:
>There are some countries that require not just a *valid* passport, 
>but one which won't
>expire for  6 months beyond when you visit a country. Is Prague in 
>one of these countries (for US citizens)?
>6 months beyond the IETF meeting), it should probably be noted on 
>the ietf page about the meeting. I couldn't
>see any information about passport expiration -- just that we don't 
>need a visa.
>

---

From: Douglas Otis <[email-masked]>
Date: Sun, 18 Feb 2007 03:10:10 -0800

The IP address of the SMTP client can be found within an ASN to uncover
a network provider.  Helos might verify, which may then also identify a
domain used by a network provider's customer.  Of course the host names
within the reverse PTR may also verify as well.  Identifying the network
provider is perhaps the most reliable, as an IP address represents a
basic element of message interchange and routing.

Bulk Unsolicited Messages (BUMs) can cause great harm.  BUMs represent a
great preponderance of message volume, and place a growing burden on
recipients.  These messages can also directly infect systems and offer
links that might then exploit thousands of flaws existing in browsers.
The United State's CAN-SPAM act of 2003 permits BUMs as long as the
recipients can find valid headers and a link contained within the
message.  Without BUMs being universally illegal, only network
provider's enforcement of AUPs prohibiting this activity protects the
Internet.

About 2% of email sources send BUMs that represent more than 80% of the
volume.  Once even more network providers decide to profit from revenues
obtained carrying BUMs, then very rapidly the Internet is likely to
suffer a breakdown created by unrestrained greed.  Rejecting messages
from abusive sources as quickly as possible is not likely to keep pace
with the rising levels of BUMs and their changing strategies.

Rather than applying pressure on network providers to enforce protective
AUPs prohibiting BUMs, some believe identifying individuals sending
messages will allow a greater portion of BUMs to be blocked.  The
concept of using domain identification techniques has already been
countered with domain tasting at a daily churn of as much as 5% of
existing domains.  SPF, Sender-ID, and DKIM offers domain identifiers
that can point to a network provider's customer's customer.

Thomas Nast created a cartoon that captures the situation rather well.
http://www.spartacus.schoolnet.co.uk/USAnast3.jpg

Efforts failing to identify those actually transmitting messages are
disheartening, as these methods overlook significant risks imposed by
the redirection tactics.  This tactics also assume someone else will
deal with the BUM problem.  The more removed from who is transmitting
the message, the less likely any enforcements efforts will be effective
in the milli-second Blitz Kreig being waged.

SPF/Sender-ID uses a DNS based script language that allows the
local-part of an email address to modify a tremendous number of DNS
transactions generated from one cached record.  SPF actually allows DDoS
to be generated by BUMs free for the attacker, and nearly impossible to
trace.

DKIM started out as a good idea, but lacks a means to identify who is
transmitting the message.  Limitations imposed by DKIM require
email-address domain owners to submit private keys to their
email-providers.  Don't worry about the replay problem, as some claim
Sender-ID has that covered.  Both of these schemes require acceptance of
the entire message, which preclude any relief from a BUM onslaught.

Organizations created by providers with a goal to offer solutions have
instead decided to ignore risks and offer solutions unlikely to even
prevent spoofing, let alone make a dent in the BUM problem.  Australia's
Spam Act of 2003 makes it illegal to send even one unsolicited
commercial email to Australia.  The maximum daily penalty is $1.1
million for companies and $220,000 for individuals or anyone knowingly
involved.  At least the Aussies appear to grok the severity of the
problem.

-Doug

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 18 Feb 2007 12:48:39 +0100

> basic element of message interchange and routing.

Identifying the previous hop, you mean.

If this was effective, blacklists would have solved the spam problem.

If you're lucky (no relays), you're identifying the botnet component that 
was hijacked into sending the message.

Haven't we been here before?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 18 Feb 2007 12:51:09 +0100

On second thought, I know that you know this field well enough that I 
*must* have misunderstood your message.

Could you please restate your missive in such a way that it's clear:

- What problem you think the IETF can help solve
- What action you think the IETF should take to solve it?

I'm afraid the whole spam thing has gotten so convoluted by now that I need 
instructions in large type to figure out which path out of the weeds you're 
pointing at....

                 Harald

---

From: Tony Finch <[email-masked]>
Date: Sun, 18 Feb 2007 12:46:08 +0000

> If this was effective, blacklists would have solved the spam problem.

They are 90% effective which I think is pretty good. You can't expect to
eliminate spam, so using 100% effectiveness as a criterion for "solving
the spam problem" is pointless.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
DOGGER: NORTHWEST 4 OR 5. SLIGHT OR MODERATE. MAINLY FAIR. MODERATE OR GOOD.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 18 Feb 2007 13:20:05 -0800

> instructions in large type to figure out which path out of the weeds you're 

There is a very dangerous trend developing in how email and network
providers wish to deal with bulk unsolicited messaging.  In essence,
their desire is to hold content originators accountable.  At the same
time, are promoting identification strategies that obscure who is
actually transmitting the message.  Although identifying the domains
creating message content might seem ideal, not identifying the domain
transmitting the message is highly perilous from a network security
standpoint.

Case in point would be Sender-ID.  Here the SMTP client's IP address is
authorized by matching it against a possible originating domain's list
of all IP addresses used publicly within the Internet.  A safe
alternative (that does not attempt to obscure the transmitting entity)
would be to first authenticate the transmitting entity, and then check
whether an originating domain has authorized the transmitting entity.
The transmitting entity can be authorized using a "Name-Hash" with one
small and safe DNS transaction.  Sender-ID's efforts to obscure the
transmitting entity has created an extremely dangerous DDoS threat
instead.

Case in point would be DKIM.  Here the originating email-address is
assured _only_ by the signature of a parent domain.  DKIM could have
been structured to allow the signature to always be applied by the
transmitting entity instead, and then allow this entity to be authorized
by originating domains when the domains differ.  DKIM lacks a means to
identify on who's behalf the signature was applied when the domains
differ, and a means for originating domains to authorize the
transmitting entity.

DKIM's signatures can be replayed, as can any crypto-graphic signature.
DKIM's strategy to obscure the transmitting entity means a definition
must now be establish as to which upper portions of the domain hierarchy
can be considered authoritative for email-addresses.  In addition,
email-address domain owners that outsource email services will need to
exchange private keys on a large scale with these transmitting entities.
DKIM's efforts to obscure the transmitting entity means MTAs will
warehousing thousands of private-keys.  In addition, the diffusion of
DKIM signatures at the transmitting entity also makes dealing with
replay abuse virtually impossible.

---

The safe way forward would be to demand that security be considered
first and foremost.  In a store and forward scheme, start the chain of
identification from the transmitting entity, where the originating
entity is then able to authorize the transmitting entity when they
differ.

---

For Sender-ID, validate the SMTP client, and then allow the PRA to
authorize the SMTP clients using a small single "Name-Hash" DNS
transaction.

For DKIM, allow the signature to indicate on which header's behalf the
signature was applied.  This could be done by extending the 'i='
semantics, or more simply by naming the header.  A small single
"Name-Hash" DNS transaction could then safely authorize the transmitting
entity.  This removes the need to establish which elements of the domain
hierarchy are authoritative for email-addresses, and removes the extreme
risk created when exchanging and warehousing private keys at
transmitting MTAs, as the current scheme now demands.

In either approach, having a strong identifier of a transmitting entity
allows a much faster response to abuse.  The current trend of obscuring
the transmitting entity must be stopped, or the IETF will face the
perils these schemes will surely create.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 19 Feb 2007 09:03:34 -0800

On Sun, 2007-02-18 at 13:20 -0800, Douglas Otis wrote:

---

---

As clarification, validating public transmitters, and assuring
email-addresses by way of transmitter authorizations should be
considered separate events.  In the case of DKIM, it is much easier and
safer to distinguish between public and private transmissions.  This
recommendation should not be considered a suggestion for reverting to
using something as cumbersome as bang addressing.

Identifying public transmitters permits feedback that can offer
protection for IP address reputations.  Nor will email-address
assurances identify message authors.  The lack of a transmitter
authorization where such is normally obtained simply signals recipients
to be cautious with a message.

-Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2007 13:31:59 +0100

On 2007-02-18 13:46, Tony Finch wrote:
> They are 90% effective 

You what? Which Internet would that be?

Blacklists at the level of sending domains (or reputation systems
that function like blacklists) are a failure. Maybe you are fortunate
and dotat.at is not blacklisted. You won't feel so fortunate when
it does get blacklisted one day, if you happen to find out why
your mails are being dropped.

      Brian

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 Feb 2007 16:07:55 +0000

On Wed, 21 Feb 2007, Brian E Carpenter wrote:
> that function like blacklists) are a failure.

I was talking about IP address blacklists. Perhaps 90% was a bit
over-optimistic - my stats from cam.ac.uk show more than 80% of spam dealt
with by DNS blacklists and another 10% with a few other simple checks.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE: SOUTHEAST 6 TO GALE 8. ROUGH OR VERY ROUGH, OCCASIONALLY
HIGH. OCCASIONAL RAIN OR SLEET. MODERATE OR POOR.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Feb 2007 12:44:22 -0800

On Feb 21, 2007, at 4:31 AM, Brian E Carpenter wrote:

> that function like blacklists) are a failure. Maybe you are  
> fortunate and dotat.at is not blacklisted. You won't feel so  
> fortunate when it does get blacklisted one day, if you happen to  
> find out why your mails are being dropped.

The preferred solution would be to abolish email black-hole lists,  
and rely upon effective AUP enforcement of network providers that  
prohibit bulk unsolicited messaging.  Unfortunately some countries,  
such as the United States for example, permit bulk unsolicited  
messages following a few guidelines that are rarely enforced.  In  
addition, the US law also prevents victims of bulk unsolicited  
messages from seeking relief in court, as only providers and the US  
government have standing.

The level of bulk unsolicited messages exceed more than 90% of the  
volume in many cases, where a majority commonly see figures in excess  
of 80%.  Without use of email black-hole lists, many systems become  
saturated with unwanted messages.  This is particularly true where  
network bandwidth is the limiting factor.  Both Sender-ID and DKIM  
require entire messages to be received before acceptance criteria can  
be applied.  Methods to identify and filter messages based upon  
originating email-addresses will not offer any relief, where a high  
turnover of millions of domains every day makes this effort far less  
effective as well.

Nevertheless, bulk unsolicited messages are also effective at  
infecting or enticing victims.  These messages must be stopped.  No  
email black-hole list can be 100% effective, but can eliminate much  
more than two-thirds of this unwanted traffic.  This reduction often  
rescues resources needed for message analysis aimed at improving  
basic security protections.

Black-hole lists also have false positives.  At times, false  
positives encourage network providers into either establishing or  
enforcing AUPs that prohibit bulk unsolicited messages.  Only network  
providers can adequately deal with this problem, as the messages must  
be prevented before they are sent.  This remains an ugly and ongoing  
process, where outright banning of bulk unsolicited messaging is  
really the only practical solution.  Such prohibitions can be effective.

At any point in time, about 2% of the sources are creating a  
problem.  Of course, these 2% are those not yet black-hole listed as  
well.  The amount of abuse from black-hole listed sources quickly  
becomes nil.  Black-hole listing the address space of providers that  
ignore bulk unsolicited messages coming from their networks can also  
be effective at eventually changing their policies.  No source should  
be listed for 5xx without first contracting the network provider as  
determined by the ASN.  The network provider is the only suitable  
actor able to resolve this problem.  Black-hole lists are just an  
ugly band-aid.  However, time and time again, the network provider's  
role is ignored in the various email strategies.

Something that could greatly assist the network provider would be a  
scheme that identifies the entity actively transmitting the  
messages.  The transmitter's IP address can become black-hole listed,  
should the entity running the transmitter not become aware of a  
problem.  Transmitter identifiers would also benefit network  
providers in that their customers could be directly contacted  
instead.  Unfortunately, the transmitter remains obscured in all the  
emerging standards.

-Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Feb 2007 10:16:43 +0100

On 2007-02-21 17:07, Tony Finch wrote:
> I was talking about IP address blacklists.

Right. That can work, of course.

> Perhaps 90% was a bit

Interesting. Do they also run content filters?

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Feb 2007 10:41:45 +0100

> The level of bulk unsolicited messages exceed more than 90% of the volume in many cases

I estimate 95% of moderated non-member mail that hits the IESG list to be b.u.m.

    Brian

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Feb 2007 19:21:27 +0000

> Interesting. Do they also run content filters?

SpamAssassin deals with most of the rest.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
PLYMOUTH BISCAY FITZROY SOLE: SOUTH OR SOUTHWEST 5 TO 7, OCCASIONALLY GALE 8.
ROUGH OR VERY ROUGH. RAIN AT TIMES. MODERATE OR GOOD.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Feb 2007 11:29:50 -0800

On Feb 22, 2007, at 1:41 AM, Brian E Carpenter wrote:

>> volume in many cases

Much that slips past somewhat static (and not very effective) lists  
come from a small percentage of network providers not managing  
prohibitions of bulk unsolicited messages.  On one hand, network  
provider's revenues depend upon traffic, any traffic.  On the other  
hand are support calls.  Effective black-hole operators only deal  
with network providers.  Network providers can stipulate which  
address ranges are placed on the black-hole operator's policy based  
lists.  When bulk unsolicited messages are detected from sources  
enabled by the network provider, the network provider is contacted  
first.  Deference is afforded when a network provider responds, where  
avoiding a listing is truly a shared interest.

Customers of network providers that do not to respond to reports, and  
that also have a high density of IP addresses emitting bulk  
unsolicited messages are unfortunately at risk.  When a customer  
becomes listed, the black-hole list operator will likely inform them  
they must contact their network provider, as the network provider  
must act on their behalf.  It is impossible to develop relationships  
with billions of network provider's customers, where those wishing to  
send bulk unsolicited messages are also often less than truthful.   
Short of making bulk unsolicited messages outright illegal or  
permitting complete mayhem, the tussle remains between black-hole  
list operators and network providers, an aggregate of receivers  
versus an aggregate of transmitters.

Network providers very much desire black-hole operators to  
automatically delist IP addresses when their customers complain to  
the black-hole operator.  Ongoing efforts in the ASRG voice this  
desire in a draft aimed at advising black-hole list operators.  This  
draft does not clarify how network providers are identified, or  
attempt to describe the network provider's role in controlling bulk  
unsolicited messaging.  Ignoring the role of the network provider may  
be extremely profitable for some, but is also likely to be highly  
detrimental for the Internet as a whole.

A better way to deal with this problem would be to impose stiff  
sanctions on network providers who fail to handle reports of bulk  
unsolicited messages.  This will mean they need to deal with  
fraudulent accounts or block infected computers.  Currently, the PITA  
created by black-hole lists create some financial incentive that  
restrains BUMs at their current, albeit high, levels.  Ignoring the  
role network providers play in controlling bulk unsolicited messages  
will likely allow this problem to grow much worse.

-Doug