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

sieve elérés gond

Van egy mail szerver, dovecot van rajta. Kis cég belső hálózatán.

Debian verzió frissítés (squeeze-re) után a thunderbird sieve pluginjával nem tudták már piszkálni a szűrőiket. Maga a szűrés ment továbbra is.Nézegettem egy kicsit, kiderült, hogy nem is figyel sehol sem. Beállítottam a dovecot konfigban, hogy figyeljen a sieve porton.

Most lokálhostról telnettel be tudok lépni és PLAIN auth után tudom kézzel listázni a teszt scriptemet.
Távolról megpróbálva belépni tudok kapcsolódni, de PLAIN auth nem megy, azt mondja, helyesen, hogy titkosítás nélkül ő nem hajlandó jelszavakat elfogadni.

Viszont a Thunderbird kliens csak próbál kapcsolódni, aztán nem történik semmi.

dovecot konfig rész:

protocols = imap imaps pop3 pop3s managesieve
protocol managesieve {
  listen = *:4190
  mail_debug = yes
}
protocol lda {
  mail_plugins = sieve
}
auth default {
  mechanisms = plain
}

Thunderbird sieve beállítás
port 4190
authentication: use login from IMAP account
secure connection: true (Force TLS)

A mail szerveren a mail logban semmi bejegyzés nem keletkezik, amikor a sieve kliens elméletileg épp kapcsolódni próbál.

Nem tudom, az lehet-e gond, hogy az IMAP-hoz SSL/TLS van beállítva és nem STARTTLS.

Illetve okozhatja-e a gondot, hogy a szerver tanúsítványának a neve eltér:
a mail szerver nevére szól (valószínűleg egy telepítéskor létrejött self signed cert az), a külvilág felől meg a tűzfal IP címe látszik, ami más névre oldódik fel.
Levelek lekérdezésekor erre panaszkodik a TB, ezt kivételként hozzá lehet adni.
De a sieve nem kérdez, illetve ha IMAP-nál hozzáadtam, utána se kapcsolódik.

Valakinek működik dovecot 1 sieve thunderbird pluginnel? Milyen beállítás rossz/hiányzik nálam?

Nginx vs .htaccess

Kostolgatom az Nginx -et, sikerult is beloni, de valami nem az igazi: ha egy GET parameter szokozt tartalmaz, akkor megbolondul, mert nem jol ertelmezi a parametereket.
Nem szeretnek tulsagosan belemenni a reszletebe, azt biztosan tudom, hogy a rewrite -al van a gond, mert apache -al rendesen mukodik.

Az adott szerveren lenne tobb web app ( ebben a peldaban a demo/app1 lenne ).

/var/www ->root

/var/www/demo/app1/.htaccess:

RewriteEngine on
RewriteRule ^$ public/ [L]
RewriteRule (.*) public/$1 [L]

/var/www/demo/app1/public/.htaccess:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ index.php?url=$1 [PT,L]

-------------------
Ez nginx -ben igy nez ki:

location /demo/app1/ {
index public/index.php;
if (!-e $request_filename) {
rewrite ^/demo/app1/(.*)$ /demo/app1/public/index.php?url=$1 last;
}
}

Mint mondtam nem szeretnek tulsagosan belemerulni a reszletekbe, hogy mi es miert, csak annyiban szeretnek segitseget kapni, hogy hogyan javitsam ki a rewrite -ot.
Koszonom!

Nginx reverse proxy Apache-hoz

Debian alatt csináltam egy webszervert Apache előtti Nginx reverse proxy-val.
Működik is minden, egy apró hibától eltekintve

A mysyte.com/akarmi megnyitásakor a mysyte.com:8080/akarmi/ -re irányít, mysyte.com/akarmi/ eresét helyesen a mysyte.com/akarmi/ -ra.

port_in_redirect off; az nginx configban nem segített.

Valaki?

Google mint spamszűrő

Sziasztok!

Van egy postfix, amiben vannak átirányítások. pl info@domain.example -> doamin.example@gmail.com

Néha a google visszadobja a levelet egy időre ezzel az üzenettel:

(host alt1.gmail-smtp-in.l.google.com[74.125.25.26] said: 421-4.7.0 [xx.xx.xx.xx] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0 http://www.google.com/mail/help/bulk_mail.html to review our Bulk 421 4.7.0 Email Senders Guidelines. po7si14890051pbb.66 - gsmtp (in reply to end of DATA command))

Elolvastam az üzenetben levő linket, de tanácstalan vagyok.
Mit kell/lehet ilyenkor tenni?
Nem lehet a google-től előre lekérdezni, hogy vajon ez az e-mail átmenne-e hozzá vagy sem?
Hasonlóan ahogy meg lehet adni a postfixben ilyet: "reject_rbl_client zen.spamhaus.org"

Üdv: redman

Exim4 nem ellenőrzi az SPF és DKIM-et

Sziasztok!

Rövid küzdelem árán beüzemeltem a DKIM és SPF rekordokat a cégnél, ezek ki is mennek.
Befele már érdekesebb a helyzet, mert hiába engedélyeztem az ellenőrzési folyamatot az SPF-nél, mintha semmi se történne.
Az spfquery megvan, és kézzel paraméterezve jó válaszokat kapok.


#00_exim4_config_custom_settings
CHECK_RCPT_SPF = 1

#30_exim4_config_check_rcpt

  .ifdef CHECK_RCPT_SPF
  deny
    message = [SPF] $sender_host_address is not allowed to send mail from \
              ${if def:sender_address_domain {$sender_address_domain}{$sender_helo_name}}.  \
              Please see \
              http://www.openspf.org/Why?scope=${if def:sender_address_domain \
              {mfrom}{helo}};identity=${if def:sender_address_domain \
              {$sender_address}{$sender_helo_name}};ip=$sender_host_address
    log_message = SPF check failed.
    !acl = acl_local_deny_exceptions
    set acl_m9  = -ipv4=$sender_host_address \
                  -sender=$sender_address \
                  -helo=$sender_helo_name
     condition   = ${if eq {$runrc}{1}{true}{false}}

  defer
    message = Temporary DNS error while checking SPF record.  Try again later.
    !acl = acl_local_deny_exceptions
    condition = ${if eq {$runrc}{5}{yes}{no}}

  warn
    condition = ${if <={$runrc}{6}{yes}{no}}
    add_header = Received-SPF: ${if eq {$runrc}{0}{pass}\
                                {${if eq {$runrc}{2}{softfail}\
                                 {${if eq {$runrc}{3}{neutral}\
                                  {${if eq {$runrc}{4}{permerror}\
                                   {${if eq {$runrc}{6}{none}{error}}}}}}}}}\
                                } client-ip=$sender_host_address; \
                                ${if def:sender_address_domain \
                                   {envelope-from=${sender_address}; }{}}\
                                helo=$sender_helo_name

  warn
    log_message = Unexpected error in SPF check.
    condition = ${if >{$runrc}{6}{yes}{no}}

  accept
    log_message = SPF record is OK.
  .endif

Több domain külön certtel, azonos wwwroot

Üdv,

Van egy weboldalam, ami a /www/oldalam alatt található. Ehhez eddig volt az oldalam.hu domain és egy startssl cert. Most regisztrálásra került az oldalam.com és ehhez is egy startssl cert. Szeretném azt elérni, hogy az apacheom mindkét domaint kiszolgálja ugyanazzal a docroot-al, viszont különböző certttel.

Próbáltam új configba beirni az új domaint és certet, viszont ebben az esetben nem indul el az apache és a logokba sem ir semmit...

Mi lehet a gond?

Spam miatt tíltólisára tettek 1 IP címet

Hellósztok!

Ez a spam szűrés hogy van? Mennyi idő után ürül stb?
Történet:
Tegnap este az egyik ügyfélnek a jelszavát vagy feltörték vagy valami hasonló és egy iphone-ról küldözgetett több tízezer levelet összevissza.
Jelszó módosítás és levező szerver újraindítás után már visszaállt a rend.
Viszont az IP cím U_P_C-nél és pár cégnél spam listára került.
Ez automatikusan deaktiválódik vagy ez hogy történik?

Köszönöm

IMAP megőrült

A problémám az, hogy elütnek, meg előbukkannak levelek. Elkezdi újra letölteni a rendszer az összes levelet, aztán megint eltűnik jó pár levél. Érdekes, hogy mindig csak ugyan azok a levelet maradnak meg.
Webmail -en, thunderbird, és outlook -ban is ugyan ez a helyzet.
Találkozott már valaki ilyennel? Ötlet megoldásra? Már feltúrtam a fél netet.

Debian 6, courier imap

Lehetséges megoldás:
Újratelepítettem courier -t és most jónak tűnik.