To rephrase a bit what Ron Trunk already said:
However, what prevents this computer from tagging his frames with the
Nothing. There's nothing you can do from a switch administrator's perspective to prevent this. If the connected computer has the capability to send tagged frames, it may do so.
and being able to communicate with any VLAN3 even if he belongs to VLAN1?
Now here's something a switch admin can (and probably should) do, in (at least) two ways (and some add-on).
- By dropping any incoming tagged frames on the port, and by mapping any incoming untagged frames into VLAN x, and by stripping the (internal) VLAN tag "x" from any outbound frame before forwarding it out of the given switch port (Cisco speak:
switchport mode access and
switchport access vlan X)
- By restricting the set of 802.1q tags the given switchport will accept inbound and forward outbound, and by dropping the rest (Cisco lingo:
switchport mode trunk and
switchport trunk allowed vlan <myListOfVlans>). Optionally with a definition what happens to untagged frames on the given switch port (Cisco:
switchport trunk native vlan X).
- (vendor specific) by disabling any protocol that would allow dynamic negotiation of trunking/non-trunking mode of the given port (Cisco: setting the switchport mode explicitely
switchport mode access|trunk, as above, and by disabling Dynamic Trunking Protocol with
Does it mean that Access mode architecture is prefered for security
Running all and every port untagged will sooner or later show some scaling (cable and port density) and cost issues, worsened by growth of the computing infrastructure.
In the end, it mostly will depend on the level of trust between computing infrastructure ("the server admins") and the network infrastructure ("the network admins") and what the given security policies mandate.
Some policies will say to never mix VLANs of different security zones (as in "internal" vs "DMZ" vs "external") on the same 802.1q trunk , while some will let you mix internal and DMZ while keeping external VLANs separated, and some may just not care.
 mandating not to mix internal/dmz/external VLANs on a given 802.1q trunk to a server/computer also suggests to segregate switching platforms for internal/dmz/external. After all, if a 802.1q trunk to a server/computer may not contain VLANs of different security zones, why should a trunk between two switches be allowed to? Still, there may be good reasons to run the internal VLANs and the dmz VLANs on separate trunk links from the same single switching platform to the same single host, but again, it's all up to the given security and operational policy to allow or forbid.