Beiträge von mainziman

  • Webhosting akzeptiert beliebigen Absender

    Zitat von not-a-robot

    Das Feature "Send on Behalf" kann man auch bei meinem Vorschlag einfach unterstützen.

    nicht wirklich; wie in meinem Beispiel ja gezeigt, hast Du im E-mail-From die Office-Adresse, und dessen SMTP-Passwort im ganzen Unternehmen weiterzugeben

    ist weder praktikabel und oft auch nicht gewollt;

    darum sagte ich ja, wenn dieses Feature möglich sein soll, muss man auch mit Absenderadressen absenden dürfen, welche nicht de, SMTP-User zugeordnet sind;

    und ein Denkfehler Deinerseits bei 1) Postfachadressen können keine Alias-E-mailadressen bei anderen Postfächern sein;

  • Webhosting akzeptiert beliebigen Absender

    Zitat von not-a-robot

    Davon abgesehen, was hält Netcup davon ab die Konfiguration "richtig" zu machen, und per SMTP nur die Absender zuzulassen, die auch entsprechend für diesen SMTP Account eingetragen sind?

    hier gibts ehrlich gesagt kein richtig und kein falsch;

    aber würde es derart restriktive gehandhabt werden, dann würde dies bedeuten, dass

    wenn jemand nur eine Domain hat, aber da mehrere Postfächer, dann ist das sogenannte

    "Send on Behalf" gar nicht möglich, weil - nehmen wir das Beispiel:

    es gibt ein Postfach office@company.tld und zwei Postfächer mitarbeiter1@company.tld bzw. mitarbeiter2@company.tld

    der Mitarbeiter 1 will die Mail so versenden, dass sie beim Empfänger (dem Kunden) so ankommt,

    dass dieser sieht, dass der Absender zwar office@company.tld ist, diese aber von mitarbeiter1@company.tld stammt;

    würde im Mailheader beim Empfänger so aussehen

    Code
    From: "Company" <office@company.tld>
Sender: "Mitarbeiter 1" <mitarbeiter1@company.tld>

    würde dies tatsächlich so konfiguriert sein, wie Du es vorschlägst, geht das nicht,

    und soll dies gehen, dann kann der SMTP-User mitarbeiter1@company.tld  selbstverständlich mit der Adresse office@company.tld versenden,

    welche aber einem anderen SMTP-User zugeordnet ist ...

    würde der Empfänger (= der Kunde) bei diesem Mail auf 'Antworten' gehen, dann geht die Mail richtigerweise an office@company.tld

    im Outlook sieht die Mail beim Kunden so aus: (auf das wesentliche reduziert)

    pasted-from-clipboard.png

  • Domain Transfer (.net) zu netcup: DNS Einträge/zonefile ohne Downtime

    Du kannst die Ablöse Deiner DNS Server direkt durch die von netcup mit der übersiedlung in einem Ruck machen ...

    an der Stelle wo Du die DNS-Einträge bei der 'Bestellung' (= Transfer) eingibst,

    brauchst Du nur die aktuellen DNS-Einträge eingeben;

    musst nur Sorge tragen, dass während der Phase des Umzugs keines der Lets Encrypt Zertifikate ungültig wird,

    damit Du nach der übersiedlung an Stelle Deiner DNS-Server die Netcup-DNS-Server einbauen kannst;

    das ist alles ...

  • Das längste Thema

    der Westautobahnladen in AT hat echt a lange Leitung; ein SPAM-Anruf,

    sie stellt sich vor, und ich: "wieso rufen sie mich an?",

    sie: "ja weil sie yesss Kunde sind und yess gehört der A1 Telekom,

    wir haben ein Geschenk f. sie: zu Hause f. 3 Monate Internet kostenlos"

    ich: "ich hab schon was besseres, es sei denn sie liefern mir 1 Git Bandbreite"

    sie: "ach sie haben schon A1 Festnetz ...., da sind aber nur 80 MBit möglich"

    ich: "nein ich hab was besseres"

    ...

    dann ich: "schenken sie keinem einen Skoda, der schon einen Ferrarri hat"

    erst dann hat sie es geschnallt :D

  • Das längste Thema

    Zitat von killerbees19
    Code
    host a1-at.mail.protection.outlook.com[104.47.13.36] said: Recipient address rejected: Access denied. AS(201806281) [HE1EUR04FT028.eop-eur04.prod.protection.outlook.com]

    wie darf man das interpretieren, dass hier Microsoft sich selbst bannt? oder wie kommt es dass da 2 verschiedene outlook.com hosts zu sehen sind?:D

    Zitat von killerbees19

    Aber immerhin sind wir uns durchaus einig, dass bei PHP einiges Murks ist. Dazu gibt es tatsächlich nichts mehr hinzuzufügen^^

    bei dem die Mglkt. besteht, dass er durch Updates nicht kleiner sondern größer wird :D

  • Das längste Thema

    Zitat von killerbees19

    Denn letzten Endes wird es dadurch leichter, dass man gravierende Bugs einbaut.

    das ist egal, denn jede Programmiersprache hat ihre Tücken; Dein Beispiel zeigt nämlich auch, was typisch f. quick and dirty ist;

    im Falle wenn Du statt '' wirklich NULL verwendest, ist es sogar sinnlos,

    denn wie Du ja sagtest GET/POST Arrayelemente sind garantiert Strings und unset bzw. das explizite setzen auf NULL

    machen bei isset keinen Unterschied =O

    nebenbei: macht man das auch nicht; es würde auch keiner in C auf die Idee kommen argc bzw. argv zu ändern;

    (auch wenn es Variablen sind, sollte man als Programmierer diese dennoch so wie Konstanten behandeln - nur lesen und nicht ändern)

    PHP
    $x = NULL;
var_dump( $x );
var_dump( isset( $x ) );   // die Notwendigkeit von var_dump ist hier ebenfalls Murx:
echo isset( $x );          // hier wird nichts(!) ausgegeben
$x = 0;
var_dump( $x );
var_dump( isset( $x ) );
echo isset( $x );          // hier wird aber seltsamerweise '1' ausgegeben, konsequent sieht anders aus ...

// bei PHP ist mehr Murx, nicht nur das Konzept der schwachen Variablentypisierung;

  • Das längste Thema

    KB19 doch ich hab es schon verstanden, und genau diese Sache ist ein hervorragendes Beispiel dafür welcher Designfehler in PHP unterlaufen ist;

    es geht um das, und an Stelle des Vergleichsoperators mach ich jetzt einfach §

    PHP
    if ( preg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]) § $_GET["var"] );
else
{
  ...
}

    an Hand der Regexp sollen Zeichen welche weder Buchstaben (Groß- od. Klein-) noch Ziffern oder - sind,

    herausgefiltert werden;

    interessant ist der Fall in dem tatsächlich ausschließlich Ziffern in $_GET["var"] vorkommen;

    f. den Fall, dass hier PHP meint¹, dass dies ein Integer ist, passiert mit === eher ein Murx als was sinnvolles;

    warum?

    links davon hast einen String und rechts einen Integer, und eben weil des nicht passt gilt der else-Zweig(!)

    obwohl es aber vollkommen korrekt wäre, sind ja nur Ziffern ...;

    darum empfehle ich hier == und nicht ===;

    ¹ wenn nicht im aktuellen Release, dann vielleicht in einem zukünftigen Release;

    und genau diese Dinge, welche im PHP-Konzept mit dem 'schwachen Typisierung' einhergehen,

    machen diese Sprache aus; auch wenn die Syntax der von C sehr ähnlich ist, ist sie dennoch grundverschieden;

    z.B. ein strtol wird man in PHP vergeblich suchen, ebenso die Umkehrung ltoa ;

    darum auch die unterschiedlichen Operatoren, welche es in z.B. in C nicht braucht;

    PHP
    $i = 2;
$j = 3;
echo $i . $j; // 23
echo $i + $j; // 5

    es muss jeder f. sich entscheiden, ob er auf dem Layer in PHP programmiert, oder Benutzereingaben gehärtet z.B. mit PUT statt GET und mittels CGI-Script - kann ein C Programm sein - abfängt/absichert;

  • Das längste Thema

    KB19 wenn das hier === an Stelle von == braucht,

    dann schmeiß besser den ganzen PHP-Kram hin, weil der taugt dann genau NULL:P

    ich hoff ja doch dass preg_replace einen String und keinen Scheibenkleister als Rückgabe-Typ hat;^^

    man muss es net übertreiben und == als ätzend betrachten und nur noch === verwenden;;)

  • Das längste Thema

    m_ueberall Zusatz wenn man preg_replace an Stelle von preg_match verwendet, dann sollte es schon so gemacht werden ...

    PHP
    if ( preg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]) == $_GET["var"] );
else
{
  ... // errorpage
  exit;
}

    weil dass ich nach dieser "Unprüfung" das $_GET["var"]  konsequent nirgends mehr verwendet wird,

    glaub'ich nicht, dazu kenn ich meine Pappenheimer nur zu gut;

  • Das längste Thema

    Zitat von Bensen

    Ich habe kein Zugriff auf das Script. Ich weiß nur das die GET-Parameter auf diese Weise geprüft werden.

    das da prüft aber nix

    Code
    preg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]);

    sondern vielmehr

    Code
    $value = preg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]);

    steht dann in der Variable $value genau das um die anderen Sachen (invertierte Regexp '^') reduzierte drin,

    was aber kompletter Unfug ist;

    Beispiel:

    lt. dieser Regexp will man ausschließlich auf Buchstaben (groß und klein), Ziffern und '-' filtern;

    und demnach ist dann z.B. die Eingabe von /?var=+FA-46 gültig,

    weil ja nur das '+' weggefiltert wird, // $value = 'FA-46'

    an Stelle es komplett f. ungültig zu erklären (das macht meine Variante);

  • Das längste Thema

    Zitat von Bensen
    PHP
    preg_replace('/[^a-zA-Z0-9\-]/', '', $_GET["var"]);

    Könnte ich jetzt noch auf irgendeine Weiße trotzdem Schadcode in ?var einschleusen oder ist dies nicht mehr möglich?

    ja ist immer noch möglich,

    weil aus Sicht des Programmes schreibst Du den korrigierten Input wohin?

    wieso beendest Du das Skript nicht einfach mit der einfachen Logik?

    Code
    if ( preg_match( "/^[0-9A-Za-z\-]*$/", $_GET['var'] ) == 1 );
else
{
  ... // error page
  exit;
}
... // next instruction

  • Das längste Thema

    Zitat von tab

    Naja, mehr als 1 Minute googeln kostet sie das aber auch nicht.

    wohin denkst Du, dich werden Teenies auch anstarren wie ein Mondkalb;

    deren IT-Wissen beschränkt sich auf Facebook, YouTube und WhatsApp :D

    und man tauscht keine Nummern aus,

    sondern WhatsApp werden heutzutage ausgetauscht;:D

    und wennst noch mehr angestarrt werden willst wie ein Mondkalb dann

    stelle die Frage nach der Farbe von Kühen¹ od. nach einem IBAN² :D

    ¹ Kühe sind lila, Milka ist der hinreichende Beweis:P

    ² die Wahrscheinlichkeit dass sie hier Papas Kreditkartennummer ausplaudern ist durchaus gegeben;)