me: smtp

Use your uwaterloo.ca email through Gmail.

Want to use your uwaterloo.ca email through Gmail and have no one be the wiser?

  1. Go into the gmail “mail settings” -> Accounts and Import -> Send Mail as section
  2. Follow the steps as they appear
  3. Check off “Send through uwaterloo.ca SMTP servers”
  4. Ensure the correct server is listed (should be the one you use to log in to mail i.e. mailservices.uwaterloo.ca)
  5. Enter your user name and password
  6. Select port 465
  7. Save changes

Thanks to Stephen in Science for this.

8th August 2011

Quite a Monday. A mini drama at work, with the fix task hampered by being asked to explain SMTP open relays to someone who was never going to understand it, even if I was the world’s best explainer of ‘stuff’.

Email problems sorted.

A friend who runs a pub sent me a text message after lunch, he wants to serve the Italian lager Peroni on draught to his customers, customers who chose it from a few options in an open vote. Peroni was the winner by a long way and the decision was taken to stock it. Suppliers were called and the launch date anticipated. The text? Yes, the text was to inform me that a representative form Miller Brands, the UK Peroni licence owners, had called round to assess the suitability of the establishment and clientele for their product, as they only like it sold in high class establishments to a better class of person. She was shown the door and told where to stick her high class Italian beer; but how can organisations get away with this corporate snobbery in this day and age, in this economic climate?! What if the clientele were 99% ethnic minorities, surely they wouldn’t get away with refusing to let a bar sell it on this basis? Time and time again, Mr Normal, Mr Harmless and Mrs Nothing-Special seem fair game for discrimination and lousy treatment. I will not be drinking Peroni ever again, I feel it would taste bitter.

The working day over and though I need to diet, I could not face healthy food, so concocted a wonderful Anglo-German fusion dinner of Bratwürst, chips, mushy peas and gravy; far more satisfying than a tuna steak with rocket.

Decided to bake some bread tonight, not done it for ages, but the evening is long and short of sitting watching twitter’s timeline go past, and facebook statuses update, I don’t generally do a lot. This must change. This diary is part of that change, and so is the bread. Found a Delia Smith recipe for the traditional crusty loaf. It’s rising now, for the first time, it’ll need at least another hour and a half of relaxation for me, and damned hard work for the yeast before it can go in the oven. And then the smell.

SMTP is a harsh mistress indeed

The Simple Mail Transfer Protocol is different from the Post Office Protocol. They both deal with Emails, but perhaps the most important difference is the fact that SMTP offers the ability to have your email client logged in to the mail server rather than logging to fetch and transmit emails to and from the client – as in the case of POP.

I learned this recently as I was experimenting with Emacs – that most revered of text editors. One of the features of Emacs is reading mail. I set up my .emacs-file for this and told it to use POP for the transfers. I did so because I never considered SMTP an alternative.

This turned out to be a huge mistake.

When I fired up Gnus (in Emacs) to see my mails I logged in to the server all right. But instead of just copying the messages from the server it transferred them to my machine and left the server empty. My main email client (Mozilla Thunderbird) was “emptied” of the emails I had there as it never actually read the mailbox contents locally.

I am now left with a few emails in my Thunderbird client and a bunch of old ones in Emacs Gnus.

Is there a way to change things back? To get the emails back on to the server (it does not belong to me and I have no control over it). What am I supposed to do?

lol @ email headers from facebook - "zuckmail"

X-Facebook: from zuckmail ([MTI3LjAuMC4x]) 

by async.facebook.com with HTTP (ZuckMail);

Date: Thu, 21 Jul 2011 17:15:00 -0700

<snip>

X-Priority: 3

X-Mailer: ZuckMail [version 1.00]

Wie der LDAP die Emails zerstörte

Eigentlich wollte ich nichts Böses bezwecken, als ich mich nach nunmehr fünf Jahren als Mitarbeiter an meiner Institution offiziell von einer Mitarbeiterin der Verwaltung als ein solcher eintragen lassen wollte.

Hintergrund

Mir ging es lediglich darum endlich wieder Zugriff auf unser reichlich mit Software gespicktes MSDNAA-Portal zugreifen zu können, in dem ich bereits als Student Software erhalten habe.

Nachdem ich mein Studium beendet hatte, wurde mir kein neuer Benutzeraccount für den Zugriff auf meine Emails (und die anderen Dienste) mitgeteilt, sondern ich durfte meinen alten Account weiter verwenden. Soweit, so gut! Doch nach ein paar Jahren wurde an der Infrastruktur “gebastelt” und mein Zugriff auf das MSDNAA war mit dem alten Account nicht mehr möglich. Also versuchte ich zunächst herauszufinden, wer denn zuständig ist für das System und musste dabei feststellen, dass die zuständige Mitarbeiterin erst noch 14 Tage im Urlaub verweilt und es (wie so oft, doch dazu gleich mehr) keine Vertretung gibt. Insgesamt ein sehr ungünstiger Zeitpunkt, hatte ich doch gerade erst ein neues Notebook erhalten, welches komplett neu installiert und eingerichtet werden musste; ohne passende Software ein schwieriges Unterfangen. 

Der Eintrag in den LDAP

Natürlich habe ich mir den Termin der Rückkehr der genannten Mitarbeiterin in den Kalender eingetragen, damit ich es nicht verpasse schnellstmöglich ein richtiger Mitarbeiter meiner Institution zu werden. Also meldete ich mich unmittelbar nach dem Urlaub bei ihr um sie höflich zu bitten, meinem überschaubaren Anliegen nachzukommen. Die Dame zeigte sich auch sehr hilfsbereit und bot an, mir gleichzeitig auch einen Mitarbeiterausweis zu erstellen, wenn ich ihr einige weitere Informationen via Email zukommen lasse. Direkt eintragen könne sie mich leider nicht, da die Webseite “kaputt sei”, die sie zum Eintragen nutzt. Diese müsse erst repariert werden. “Na gut”, dachte ich mir - das wird schon jemand richten. Ich sollte Recht behalten.

Die nette Dame aus der Verwaltung konnte einen Tag später bereits wieder auf ihr Webinterface zugreifen und hat mich in dem System als Mitarbeiter angelegt. Vielen Dank dafür!

Leider ging dabei gehörig etwas schief.

Zuerst dachte ich mir nichts dabei und habe mich gefreut, dass plötzlich an einem normalen Arbeitstag nach 08:07 Uhr keine Emails mehr empfangen habe, aber im Laufe des Tages wurde ich doch ein wenig unruhig, freute mich aber auch sehr, da doch ca. 40% meine Arbeitstages aus EMail-Arbeit bestehen. Gegen nachmittag kam ein Mitarbeiter zu mir ins Büro; er wollte mir ein paar Informationen zusenden und bekam eine komische Fehlermeldung:

SMTP-Fehler 5.1.4 duplicate/ambiguous directory match: meineEMAIL@institution.de

Sollte hier meine Vorfreude über weniger Emails doch etwas verfrüht gewesen sein?

Tatsache ist, dass beim Anlegen in dem LDAP System ein neuer Mitarbeiter eingetragen wurde, der allerdings in dem Emailsystem, welches mit dem LDAP synchronisiert wird bereits existiert. Also habe ich nun zwei Benutzerkonten, die sich eine Emailadresse teilen und einen Email-Server, der nicht weiß wem er eingehende Emails zustellen soll.

Das Problem noch selbst analysierend rief ich in der Datenverarbeitungszentrale an. Freitag, kurz vor 16:00 Uhr rechnete ich kaum noch mit Anwesenheit, wurde jedoch positiv überrascht. Überrascht hat mich allerdings auch, was ich dann zu hören bekam…  Meine Idee, um was für ein Problem es sich handelte wurde auch bestätigt. Meinem Wunsch einfach den neuen Benutzer zu löschen und die Aliase wieder “gerade zu biegen” konnte allerdings leider nicht entsprochen werden.

Chef der DVZ:

Der betreffende Mitarbeiter, der die Emailsysteme und unsere LDAPS verwaltet befindet sich leider im Urlaub.

Mitarbeiter, dessen Emails nicht mehr funktionieren (noch immer zuversichtlich eine schnelle Lösung für sein Problem zu bekommen):

Na, das macht doch nichts. Dann kann seine Vertretung das vielleicht erledigen?

DVZ:

Eine Vertretung gibt es nicht. Der zuständige Mitarbeiter ist der Einzige, der sich überhaupt mit den Systemen auskennt.

Mitarbeiter, dessen Emails nicht mehr funktionieren (nunmehr weniger zuversichtlich):

*schluck*

DVZ:

Das tut mir jetzt wirklich leid, Mitarbeiter, dessen Emails nicht mehr funktionieren, aber ich fürchte wir können Ihnen da nicht helfen.

Mitarbeiter, dessen Emails nicht mehr funktionieren (panisch):

Wann kommt der Mitarbeiter, der mir helfen kann denn zurück?

DVZ:

Da dauert noch eine Woche. Da müssen Sie sich dann wohl leider so lange gedulden. So wichtig können Ihre Emails wohl auch nicht sein.

Fassen wir also kurz zusammen

  1. Der kompetente Mitarbeiter befindet sich also im Urlaub.
  2. Es gibt keine Vertretung.
  3. Niemand weiß, wie die Server und Scripte ineinanderreifen.
  4. Und von extern kann sowieso niemand helfen. 
  5. Zwischenzeitlich darf ich eine Woche warten, dass man sich um mein Problem kümmert.
  6. Ein Absender von extern, der mir eine Email schicken möchte bekommt keine Fehlermeldung, geht also davon aus, dass die Email zugestellt wurde. Ich stehe doof dar, darf 500 Menschen eine Email schicken, die mich ggf. in den nächsten Tagen kontaktieren KÖNNTEN….

Man könnte meinen, man befindet sich in einem 1-Mann-Betrieb, in dem der Chef, gleichzeitig Ausbilder, EDV-Fachmann, Techniker und Bürokraft ist - aber eigentlich befinden wir uns in einer mittelgroßen Institution mit mehr als 300 Mitarbeitern und einer Vielzahl an Studierenden.

Ich denke, so eine Situation darf einfach nicht auftreten.
Was denkt ihr darüber?

Using Shortmail

Settings for use in shortmail:

Email Address:	YOURNAME@shortmail.com
Account Name:	YOURNAME
Password:	YOURPASSWORD
Incoming Mail Server (IMAP):	imap.shortmail.com (port 993, SSL)
Outgoing Mail Server (SMTP):	smtp.shortmail.com (port 587, TLS/SSL)
POP Server (POP3):	pop.shortmail.com (port 995, SSL)
Ausgehende Emails werden als SPAM markiert bzw. nicht zugestellt

Anfrage: Ausgehende Emails werden im Betreff als SPAM markiert bzw. werden überhaupt nicht zugestellt.

External image

Lösung: Die Ursache hierfür ist der SMTP-Server, der die Mails entgegennimmt und an den entsprechenden Mailserver des Empfängers weiterleiten soll. Der SMTP-Server prüft beim Empfang der zu sendenden Mail, ob es sich um Spam handeln könnte, um den Versand von Spam Mails zu unterbinden. Zur Prüfung wird häufig das Programm SpamAssassin eingesetzt, welches anhand verschiedener Kriterien feststellt, ob es sich um unerwünschte Spam Mails handelt. Siehe z.B. folgenden Mail-Header:

X-Spam-Flag:     YES
X-Spam-Score:   5.285
X-Spam-Level:    *****
X-Spam-Status:  Yes, score=5.285 tagged_above=0.5 required=5 tests=[BAYES_00=-1.9, EXTRA_MPART_TYPE=1, FSL_HELO_BARE_IP_1=2.347, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.695, TVD_RCVD_IP4=1.596] autolearn=no

Anhand von verschiedenen Erkennungsmerkmalen wird ein Score errechnet, der aussagen soll, mit welcher Wahrscheinlichkeit es sich um Spam handelt. Der o.g. Score von 5.285 überschreitet den eingestellten Schwellwert und aus diesem Grund wird die Mail als Spam markiert bzw. vom empfangenden Mailserver nicht entgegengenommen.

Um Mails wieder korrekt versenden zu können, nehmen Sie Kontakt mit ihrem Mailhoster auf und weisen Sie ihn auf das Problem hin. Dort kann dann z.B. der Schwellwert heraufgesetzt werden. Oder Sie prüfen, wie dieser Score zustande kommt und ändern die Einstellungen ihres Mailprogramms bzw. die Inhalte Ihrer Mail, um den Schwellwert nicht zu überschreiten (z.B. HTML_IMAGE_ONLY_20 = HTML: images with 1600-2000 bytes of word => Entfernen des Signaturbilds in der Mail.)

(25) Mail Works :)

It isn’t implemented, but I got it working. Little did I know that PHP’s mail() function requires a mail server on the server the script is running on. Well, thanks to a brief review of the book at Chapters I learned PHP from, I looked up free smtp servers, and found one that worked. Oddly, the mail() function doesn’t seem to want to work, but I have another sort of plugin that works just fine. Auto-emailing an authentication code is something I wanted from the beginning, and now I have that. Or, will have it, when I’m not starving and am able to concentrate on this project.

To food!

gmail szivatás - óriáscsatik kóvályognak valahol

Egyre többen szentségelnek, hogy a google is elkezdett belterjeskedni. Azaz minden a saját networkon belül működni látszik, de a rendszerből kifelé küldött csatolmányokat is tartalmazó levelek a napokban 2 -8 - 10 órákat is tudnak kóvályogni a net piszkos csatornarendszerében. Ez azért annyira nem frankó.

Lehet, valami para van az SMTP gatewayok környékén…

Windows Server 2008에서 SMTP 운영
  1. SMTP 부가기능 설치
  2. IIS에 종속적인 기능들 설치(자동)
  3. 필요한 경우 릴레이 설정
  4. 서비스 시작

설정 후 테스트 방법 (Telnet command) - 연결 (telnet your_ip 25) - helo me - mail from:your_account@your_domain - rcpt to:recipient_account@domain - data - 내용 입력 후 .입력하고 Enter - quit

안될 경우의 확인사항 1. 방화벽에서 포트 막혀있는지 확인 (SMTP 기능 설치시 자동으로 열려있음) 2. 릴레이 확인 (IIS 관리에서 설정 가능. 릴레이 미설정이 default. 미설정시 도메인 IP에 상관없이 메일 전송 기능) 3. SMTP 접근에 인증이 필요하진 않은지 확인 (Default로 익명 로그인 허용상태임)

릴레이 설정이 필수적이라고 보여지지만 어찌된 일인지 특정 도메인과 IP를 허용해도 전송 실패함.

The 500 mile email.

Speaking with a colleague re appropriate ping times over distance this evening reminded me of this. So I thought I root around and share.

The following is the 500-mile email story in the form it originally appeared, in a post to sage-members on Sun, 24 Nov 2002.:

From trey@sage.org Fri Nov 29 18:00:49 2002
Date: Sun, 24 Nov 2002 21:03:02 -0500 (EST)
From: Trey Harris <trey@sage.org>
To: sage-members@sage.org
Subject: The case of the 500-mile email (was RE: [SAGE] Favorite impossible
    task?)

Here's a problem that *sounded* impossible...  I almost regret posting the
story to a wide audience, because it makes a great tale over drinks at a
conference. :-)  The story is slightly altered in order to protect the
guilty, elide over irrelevant and boring details, and generally make the
whole thing more entertaining.

I was working in a job running the campus email system some years ago when
I got a call from the chairman of the statistics department.

"We're having a problem sending email out of the department."

"What's the problem?" I asked.

"We can't send mail more than 500 miles," the chairman explained.

I choked on my latte.  "Come again?"

"We can't send mail farther than 500 miles from here," he repeated.  "A
little bit more, actually.  Call it 520 miles.  But no farther."

"Um... Email really doesn't work that way, generally," I said, trying to
keep panic out of my voice.  One doesn't display panic when speaking to a
department chairman, even of a relatively impoverished department like
statistics.  "What makes you think you can't send mail more than 500
miles?"

"It's not what I *think*," the chairman replied testily.  "You see, when
we first noticed this happening, a few days ago--"

"You waited a few DAYS?" I interrupted, a tremor tinging my voice.  "And
you couldn't send email this whole time?"

"We could send email.  Just not more than--"

"--500 miles, yes," I finished for him, "I got that.  But why didn't you
call earlier?"

"Well, we hadn't collected enough data to be sure of what was going on
until just now."  Right.  This is the chairman of *statistics*. "Anyway, I
asked one of the geostatisticians to look into it--"

"Geostatisticians..."

"--yes, and she's produced a map showing the radius within which we can
send email to be slightly more than 500 miles.  There are a number of
destinations within that radius that we can't reach, either, or reach
sporadically, but we can never email farther than this radius."

"I see," I said, and put my head in my hands.  "When did this start?  A
few days ago, you said, but did anything change in your systems at that
time?"

"Well, the consultant came in and patched our server and rebooted it.
But I called him, and he said he didn't touch the mail system."

"Okay, let me take a look, and I'll call you back," I said, scarcely
believing that I was playing along.  It wasn't April Fool's Day.  I tried
to remember if someone owed me a practical joke.

I logged into their department's server, and sent a few test mails.  This
was in the Research Triangle of North Carolina, and a test mail to my own
account was delivered without a hitch.  Ditto for one sent to Richmond,
and Atlanta, and Washington.  Another to Princeton (400 miles) worked.

But then I tried to send an email to Memphis (600 miles).  It failed.
Boston, failed.  Detroit, failed.  I got out my address book and started
trying to narrow this down.  New York (420 miles) worked, but Providence
(580 miles) failed.

I was beginning to wonder if I had lost my sanity.  I tried emailing a
friend who lived in North Carolina, but whose ISP was in Seattle.
Thankfully, it failed.  If the problem had had to do with the geography of
the human recipient and not his mail server, I think I would have broken
down in tears.

Having established that--unbelievably--the problem as reported was true,
and repeatable, I took a look at the sendmail.cf file.  It looked fairly
normal.  In fact, it looked familiar.

I diffed it against the sendmail.cf in my home directory.  It hadn't been
altered--it was a sendmail.cf I had written.  And I was fairly certain I
hadn't enabled the "FAIL_MAIL_OVER_500_MILES" option.  At a loss, I
telnetted into the SMTP port.  The server happily responded with a SunOS
sendmail banner.

Wait a minute... a SunOS sendmail banner?  At the time, Sun was still
shipping Sendmail 5 with its operating system, even though Sendmail 8 was
fairly mature.  Being a good system administrator, I had standardized on
Sendmail 8.  And also being a good system administrator, I had written a
sendmail.cf that used the nice long self-documenting option and variable
names available in Sendmail 8 rather than the cryptic punctuation-mark
codes that had been used in Sendmail 5.

The pieces fell into place, all at once, and I again choked on the dregs
of my now-cold latte.  When the consultant had "patched the server," he
had apparently upgraded the version of SunOS, and in so doing
*downgraded* Sendmail.  The upgrade helpfully left the sendmail.cf
alone, even though it was now the wrong version.

It so happens that Sendmail 5--at least, the version that Sun shipped,
which had some tweaks--could deal with the Sendmail 8 sendmail.cf, as most
of the rules had at that point remained unaltered.  But the new long
configuration options--those it saw as junk, and skipped.  And the
sendmail binary had no defaults compiled in for most of these, so, finding
no suitable settings in the sendmail.cf file, they were set to zero.

One of the settings that was set to zero was the timeout to connect to the
remote SMTP server.  Some experimentation established that on this
particular machine with its typical load, a zero timeout would abort a
connect call in slightly over three milliseconds.

An odd feature of our campus network at the time was that it was 100%
switched.  An outgoing packet wouldn't incur a router delay until hitting
the POP and reaching a router on the far side.  So time to connect to a
lightly-loaded remote host on a nearby network would actually largely be
governed by the speed of light distance to the destination rather than by
incidental router delays.

Feeling slightly giddy, I typed into my shell:

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
        * 558.84719
        / 0.0017893979

"500 miles, or a little bit more."

Trey Harris

*Me visiting someone when they ring up the support line and after an hour of trying to get their email to work, it transpires their SMTP port setting was “Mos Eisley” and when I asked them to make sure it was our mail servers port they said yes because they didn’t want to change it and didn’t think it was important*

smtp out

Ok, I went through the steps on a CentOS 4 system, which I hope is similar enough to your setup. Here are details.

/etc/sysconfig/saslauthd:

Code:
SOCKETDIR=/var/run/saslauthd
MECH=shadow
FLAGS=
/etc/postfix/main.cf:
Code:
...
smtpd_sasl_auth_enable = yes
Code:
[machine ~]# testsaslauthd -u berhanie -p bigsecret
0: OK "Success."
[machine ~]# echo -ne '\0berhanie\0bigsecret' | openssl enc -base64
AGJlcmhhbmllAGJpZ3NlY3JldA==
[machine ~]# telnet localhost 25
220 machine.example.com ESMTP Postfix
EHLO localhost
250-machine.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN AGJlcmhhbmllAGJpZ3NlY3JldA==
235 2.0.0 Authentication successful