Oczywiście masz rację, ale to dotyczy tabeli filter. W tabeli nat nic nie stoi na przeszkodzie aby stosować politykę ACCEPT.

RETURN w łańcuchach podstawowych odwołuje się do domyślnej polityki łańcucha czyli zadziała jak ACCEPT. A dobrym nawykiem jest używanie ACCEPT DROP i REJECT tylko w tabeli filter.

Sprawdzałem. SMTP onetu działa na porcie 25. Gmail działa na 587 ale z tym portem mam tak samo jak z portem 25 i 465. Cały czas nie wiem o co chodzi bo klient Operamail wysyła majle z różnych skrzynek działających na różnych portach (z tych trzech standardowych) oczywiście poza tą skrzynką ...

Nie pasuje mi jedna rzecz, mianowicie: Gdy wysyłam maile używając klienta, a dokładnie Operamail z innej skrzynki (powiedzmy gmail) to Operamail łączy się z portem 25 serwera mailowego google. Więc dlaczego telnet albo serwer smtp xmail nie może się połączyć skoro opera może?

A można to jakoś sprawdzić?

Nie, twierdzą że żadne porty nie są zablokowane.

Ale ta regułka dotyczy tylko połaczeń http (na port 80), zatem nie będzie kolidować z udostępnianymi usługami. Chyba że chcesz udostępniać wszystkim też połączenia http (np. z konkretnymi adresami IP). Możesz to załatwić w ten sposób:

# domyślnie blokujemy
iptables -P FORWARD DROP
# usługa pod ...

Może coś w tym stylu:

#Najpierw udostepniasz jakies kilka uslug (dla wszystkich nie zależy od MAC-ów)
iptables -A FORWARD -s jakis_adres -d jakis_adres -p tcp --dport jakis_port -j ACCEPT
#Potem dodajesz uzytkownikow z "whitelist"
iptables -A FORWARD -s IP -m mac --mac-source MAC -j ACCEPT
#Dla ...

Niestety, po zdjęciu firewalla dalej mam to samo.

Na moim kompie:
$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source ...