Web, mail, IRC, IM, hálózatok

Ezt kapom a matávtól:

Oct 13 15:11:09 mailserv exim[32100]: 2016-10-13 15:11:09 1bufmv-0008Lk-E6 <= ************@example.com H=webmail.vz0.example.com (webmail) [172.16.111.2] P=esmtp S=619 id=0b8d9f772f7def00060ce3c1ac0ece7b@example.com
Oct 13 15:11:10 mailserv exim[32103]: 2016-10-13 15:11:10 1bufmv-0008Lk-E6 SMTP error from remote mail server after RCPT TO:<uzleti_ugyfelszolgalat@telekom.hu>: host mx.telekom.hu [84.2.46.6]: 451 4.2.0 <uzleti_ugyfelszolgalat@telekom.hu>: Recipient address rejected: You are greylisted for 600 seconds (see http://cgi.t-online.hu/bra02/mxtest.cgi?err=GRYLST for details)
Oct 13 15:11:25 mailserv exim[32103]: 2016-10-13 15:11:25 1bufmv-0008Lk-E6 SMTP error from remote mail server after RCPT TO:<uzleti_ugyfelszolgalat@telekom.hu>: host mx.telekom.hu [84.2.44.6]: 451 4.2.0 <uzleti_ugyfelszolgalat@telekom.hu>: Recipient address rejected: You are greylisted for 586 seconds (see http://cgi.t-online.hu/bra02/mxtest.cgi?err=GRYLST for details)
Oct 13 15:11:25 mailserv exim[32101]: 2016-10-13 15:11:25 1bufmv-0008Lk-E6 ** uzleti_ugyfelszolgalat@telekom.hu R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:<uzleti_ugyfelszolgalat@telekom.hu>: host mail2.dt-one.com [195.167.99.171]: 554 5.7.1 <uzleti_ugyfelszolgalat@telekom.hu>: Recipient address rejected: Access denied
Oct 13 15:11:25 mailserv exim[32107]: 2016-10-13 15:11:25 1bufnB-0008Lr-SL <= <> R=1bufmv-0008Lk-E6 U=Debian-exim P=local S=1650
Oct 13 15:11:25 mailserv exim[32101]: 2016-10-13 15:11:25 1bufmv-0008Lk-E6 Completed

Ha jól értem a dolgot, akkor jönnie kéne pár 451-nek, és tíz perc után mégis beesne a levél, de a matáv elhajt harmadszorra (bár a timestamp fura). Túl sűrűn próbálkozik a szerverünk?

Volna mit javítani a levelezésen, de az mxtoolbox szerint úgy egész jók vagyunk. Se blacklist, se semmi.

Volt anno egy remek addon, amivel weblapokhoz, azok bizonyos részeihez tudtam megjegyzéseket hozzáfűzni, és ezt szinkronizálta is a gépeim között. Ez már egy jó ideje kampeca, és kb. azóta is keresek hasonlót, ám eleddig mérsékelt sikerrel. Volt/van egy, amit már-már majdnem jó lenne, sajnos külső szinkronizációt használ (nem a FF sajátját), ami még elfogadható lenne, de nem működik.

TudHasznál valaki valami alternatívát?

Használ valaki nagyobb forgalmú email szervert FUSE mountolt GDrive-val?
Azaz a szerver nálad működik, de az email tartalmat a szerveredre mountolt Gdrive-ra írja.

Ha nem is gigabyte-os de több száz megás csatolmányú emaileket hogyan lehet fogadni fizetős Gmail-en?
Megoldható ez saját mail szerver üzemeltetése nélkül?

B kérdésnek külön témát nyitok.

Sziasztok,

A fő böngészők friss verziói közül (IE, Chrome, Opera, FF) csak Firefoxban nem működik a select tag option szövegének font állítása az alábbi javascript hívással:

document.body.style.fontSize = '300%';

CSS-ből sem működik.

A select font mérete változik, de ráklikkelve a legördülő menüben lévő option szövegek mérete Firefoxban nem. A többi böngészőben igen. Lásd:

https://jsfiddle.net/32sn0L37/1/

Képernyőkép Ubuntu 16 x64:
http://i.imgur.com/pxGsqec.png

Képernyőkép Windows 10:
http://i.imgur.com/jG3ISts.png

Ötlet? Köszi.

( SO-n is megfuttattam a kérdést, ha valaki kíváncsi: http://stackoverflow.com/questions/39916190/ff-css-select-option-font-s… )

Küldtem bug reportot:
https://bugzilla.mozilla.org/show_bug.cgi?id=1308466

Úgy néz ki e10 bug és a multiprocessz kikapcsolása megoldja.

O365-re jonnek a levelek, amelyeket egy 3rd party email archivalo gepre (amin a piler fut, ha ez szamit valamit) tovabbitanak. A gond ott van, hogy a jelek szerint a flow control hianyzik(?) az o365 kattintgatos oldalarol, ami azt eredmenyezi, hogy ha hirtelen jon egy nagyobb mennyisegu level, akkor azt nagy lelkesen zuditja is tovabb a piler fele az o365 szerverparkja.

Csakhogy a piler elindit mondjuk 10 worker processzt, ami praktikusan 10 smtp connection-t tud egyidejuleg fogadni. Ezen a 10-en szepen jonnek is be a levelek, de ha az o365-re egy nagyobb mennyiseg zudul rovid ido alatt, akkor a piler fele nyitott/nyitni probalt smtp kapcsolatok egy resze timeout-ra szalad. Ami azt eredmenyezi, hogy az o365 egy ndr-t kuld az adminnak.

A kerdes tehat az, lehet-e egyaltalan valamilyen flow control-t beallitani, azaz, hogy ne akarjon mondjuk 80 connection-t nyitni, hanem pl. 20-ban legyen ez maximalva. Aztan legfeljebb queue-ban tartja a leveleket, amiket eppen nem tud elkuldeni.

Mondja nekem a user, hogy vár egy levelet amazontól és nem jött meg. Mondom biztos greylisted, várjál még. Megint szól hogy de még mindig nem jött meg. Nézem a logot és ezt látom:

Sep 27 06:49:13 server postfix/smtpd[29484]: NOQUEUE: reject: RCPT from a13-15.smtp-out.amazonses.com[54.240.13.15]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Sep 27 06:54:49 server postfix/smtpd[29562]: NOQUEUE: reject: RCPT from a13-34.smtp-out.amazonses.com[54.240.13.34]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Sep 27 07:04:17 server postfix/smtpd[29864]: NOQUEUE: reject: RCPT from a13-7.smtp-out.amazonses.com[54.240.13.7]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Sep 27 07:45:39 server postfix/smtpd[30641]: NOQUEUE: reject: RCPT from a13-22.smtp-out.amazonses.com[54.240.13.22]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Sep 27 08:26:23 server postfix/smtpd[31288]: NOQUEUE: reject: RCPT from a13-40.smtp-out.amazonses.com[54.240.13.40]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=

Kap egy greylist-et, erre 5 perc múlva megpróbálja elküldeni EGY MÁSIK smtp szerverről, és ezt ismétli.

Szerintetek normális? :-)

Ilyenkor mi van? Berakhatnám whitelist-re, de az rövid út a spam áradat felé. (Sok spammer küld amazon nevében levelet...)

Ötleteket, javaslatokat várnék, hogy hogyan lehet normálisan lekezelni a manapság már általánossá vált content delivery szolgáltatók szervereit és címeit a proxy jogosultságokkal összhangban?
Bizonyos site-ok működéséhez meg kell engedni ezen host-ok elérését (néha akár a proxy-t kikerülve is), de ezzel más site-ok általuk szórt tartalmának eléréséhez is engedélyt adok, amihez esetleg nem szeretnék.
Másrészt, értem én a CDN-ek hasznát és működését, de elég hibás gyakorlatnak tartom, hogy fontos site-okat (pl. szoftvercégek authentikációs, licensz szerverei) nem lehet végső megoldásként közvetlenül, ezek kihagyásával elérni.

Webes transmission felületen hol lehet állítani torrentenként a le- illetve feltöltési sebesség limiteket?

Létezik olyan browser plugin, amivel meg lehet azt csinálni, hogy mindent tiltson ami nem a címsorba beírt url domain-jéből keletkeztethető?

Az sem ártana ha lenne benne egy globális whitelist, ami minden esetben engedélyezve lenne, és url szintű whitelist is.