c-client callbacks
2010/12/17
* This is mostly for personal copy-paste reasons
Those who take the time to develop applications using UW-IMAP (or Panda IMAP) know that there are a number of callbacks that need to be defined. What follows is the simplest (do nothing) version of them.
#include "c-client.h"
void
mm_flags(MAILSTREAM *stream,unsigned long number) {
}
void
mm_status(MAILSTREAM *stream,char *mailbox,MAILSTATUS *status) {
}
void
mm_searched(MAILSTREAM *stream,unsigned long number) {
}
void
mm_exists(MAILSTREAM *stream,unsigned long number) {
}
void
mm_expunged(MAILSTREAM *stream,unsigned long number) {
}
void
mm_list(MAILSTREAM *stream,int delimiter,char *name,long attributes) {
}
void
mm_lsub(MAILSTREAM *stream,int delimiter,char *name,long attributes) {
}
void
mm_notify(MAILSTREAM *stream,char *string,long errflg) {
}
void
mm_log(char *string,long errflg) {
}
void
mm_dlog(char *string) {
}
void
mm_login(NETMBX *mb,char *user,char *pwd,long trial) {
}
void
mm_critical(MAILSTREAM *stream) {
}
void
mm_nocritical(MAILSTREAM *stream) {
}
long
mm_diskerror(MAILSTREAM *stream,long errcode,long serious) {
}
void
mm_fatal(char *string) {
}
A Unix guy dives into MS Exchange 2010
2010/11/17
Here are a two starting points:
- Exchange 2010 – A Practical Approach. Thank you XLA for locating this.
- Microsoft Exchange Server 2010 Administrator’s Pocket Consultant. Easily the “bat book” equivalent for Exchange.
re: See the Messages that Matter
2010/11/16
After reading Facebook’s blog on Messages, I thought I should write down some thoughts:
“Messages is not email. There are no subject lines, no cc, no bcc, and you can send a message by hitting the Enter key. We modeled it more closely to chat and reduced the number of things you need to do to send a message. We wanted to make this more like a conversation.”
Initially I thought of write(1). This feels like unix communiation (ytalk, irc, etc) done the Web 2.0 way. Or as some pointed out on twitter, like Wave without collaboration tools.
As for the Social Inbox, this is an implementation of a concept similar to Gmail’s Priority Inbox. Messages from people I know go into the Inbox, the rest go to the Other Inbox. Pretty simple classification mechanism (and quite effective).
“We are also providing an @facebook.com email address to every person on Facebook who wants one. Now people can share with friends over email, whether they’re on Facebook or not.”
Messages is not email, but it builds a walled garden. And like I once read (and frequently repeat) in the Internet walled gardens are doomed to communicate via SMTP.
The other side
2010/11/11
Δεν έχω συχνά την τύχη να βρίσκομαι μαζί με αρκετό κόσμο που δουλεύει με τον Exchange. Όταν όμως συμβαίνει αυτό, πάντα φεύγω έχοντας μάθει κάτι παραπάνω, όπως π.χ. την ύπαρξη των παρακάτω “ποστμαστερικών” blog που αφορούν κυρίως το συγκεκριμένο εργαλείο:
- Παιδιά! Έχουμε mail;
- Catastrophic Failure – Ιωάννα Βάθη (στα Αγγλικά)
- Catastrophic Failure – Ιωάννα Βάθη (στα Ελληνικά)
Please do not mix CNAME and MX RRs
2010/11/10
From time to time I observe the following email setups, from web hosting providers mostly:
$ host -t mx example.com example.com mail is handled by 5 mail.example.com. $ host mail.example.com mail.example.com is an alias for www.example.com. www.example.com has address 192.0.2.2
In other words this is a single server that provides web and mail services, The devil is in the details though: mail.example.com is an alias for www.example.com. This is a mistake as when something is declared as a CNAME, it cannot have other resource records bound with it. I copy from DNS for Rocket Scientists:
CNAME RRs cannot have any other RRs with the same name, for example, a TXT – well that was true until DNSSEC came along and in this case RRSIG, NSEC and certain KEY RRs can now occupy the same name.
So the above setup is wrong. The correct setup would be the following:
$ host -t mx example.com example.com mail is handled by 5 mail.example.com. $ host mail.example.com mail.example.com has address 192.0.2.2 $ host www.example.com www.example.com is an alias for mail.example.com. mail.example.com has address 192.0.2.2
That is if you want to use a CNAME at all. Personally I am using A RRs instead of CNAMEs whenever possible. But why cannot a CNAME carry any other information? I copy from RFC1034 (section 3.6.2):
A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.
So please people, correct your defaults. Your clients will benefit from that.
“Yahoo.com hates us. Suggestions”
2010/10/14
There’s an interesting thread (“Yahoo.com hates us. Suggestions“) over at the mailop mailing list. I’ve encountered almost every behavior from Yahoo! Mail servers that is documented there. Unfortunately the mailop archives are not open to the public, so you need to subscribe first.
In our case, when we deal with Yahoo! Mail delivery problems, it is almost always a case of infected machines (sometimes even a handful) sending spam …everywhere. So whenever we observe long delays while delivering to Yahoo! Mail or many many messages waiting to be delivered, we always seek for the infected. Thanks to feedback loops that are implemented by the (really) big email hubs, we also get early warning on such matters. As a matter of fact, Yahoo! Mail also runs a feedback loop, but it requires DKIM, and since we’ve stopped using DKIM (dkim-filter crashed frequently on our systems) we rely on the rest of the loops to be kept …in the loop. It seems to be working OK so far.
In “IPv6 and Email: What’s the Hurry?“, Todd Herr from Return Path argues:
As for migration strategies for email, I’m going to throw one out here that may run contrary to popular thinking: perhaps there’s no need for you to migrate your public facing email streams to IPv6 in the next few years. Instead, I propose that you slow down, focus on some other things first, and then worry about migrating.
A small conversation followed on twitter:
- @returnpath Unless we migrate right away we will not be prepared for the hordes of spammers originating from IPv6 networks
- @hakmem DKIM in place before migration may be better defense against hordes than just opening gates and using IP-based filters?
- @returnpath Everyone can score incoming messages using #DKIM but not everyone can block
- @returnpath + imagine having recipients with delivery problems on their v4 path while their v6 path is fully operational
I cannot imagine anyone in the email delivery business risking not to be able to deliver email in the dual-stack world that we are entering. Really I am not crying wolf, for yesterday Daniel Karrenberg wrote:
Imagine having a path that reaches the desired destination and not taking it. Make no mistake, situations like this will start to appear. They will be routing problems, DNS problems and other unforeseen problems in the largest network interoperability experiment ever.
Todd Herr also advices that “First, you are going to have to listen for outbound email connections on IPv6 from your own customers”. I disagree with that also. The first step is to accept IPv6 traffic on all services before creating outgoing IPv6 traffic. This means that ISPs must be able to accept email coming from IPv6 before sending. And yes I know that while the robustness principle was invented for what one accepts and sends within a protocol’s specification (i.e. what one sends and accepts in an SMTP dialog) it also applies here. One cannot have machines ready to send via a medium where no one is listening. First we build the listeners and then the senders.
The time to deploy IPv6 is now: First the routers, then the servers, next the services and last the users. So yes, you do not have to migrate your email infrastructure to IPv6 tomorrow, but spend this year planning (and testing). In a year the migration clock will be ticking.
on Priority Inbox
2010/08/31
After briefly reading about Gmail’s Priority Inbox, I think it is a product of what they are best at: classification. Using it though may change the “spaminess” of the messages in our inbox: Unimportant messages in our inbox are equally unimportant with spam messages, we just do not mark them as spam. A message can be both spam and unimportant, but not spam and important. Like @gtzi tweeted:
Could it be that people stop periodically checking their “unimportant” email just like they do with their spam folders? Do we have before us yet another automatic Trash can? I do not know.
It is really cool to see message classification technology being used for something else than spam filtering though. I remember reading in sage-members about someone using a (Bayes based) spam filter to distinguish between normal (machine generated) mail sent to the system administrator which can easily be discarded and the rest (few) that needed the administrator’s attention.
Congratulations to Google. They always seek of new ways to classify and present data.
Update: Cool infographic on Priority Inbox: Gmail Evolution
An alternative to FEATURE(mailertable)
2010/07/09
Using FEATURE(mailertable) one can instruct sendmail to route email for certain destination via a specific relay. A mailertable is essentially a static map that instructs sendmail where to route email for certain destinations ignoring DNS MX RRs (or other information). Example:
yahoo.com smtp:[server.example.com] yahoo.com.hk smtp:[server.example.com] yahoo.com.mx smtp:[server.example.com] yahoo.com.br smtp:[server.example.com] yahoo.com.cn smtp:[server.example.com] yahoo.com.sg smtp:[server.example.com]
Why would one want to do that? Your customers may have been hit by a botnet and as a result your outgoing mail server may have sent enormous amount of spam. Since most high-profile mail hubs use some kind of reputation scheme on the IP addresses that contact them, it is quite probable that your outgoing mail server is experiencing delays, or worse denied delivery despite the fact that in the meantime you have done your best to stop the botnet and clear your queues. I know for it has happened to me.
A mailertable is a quick solution to route email through another mail server just for recipient domains that implement such policies. But it is far from perfect for the Postmaster has no way to know all the domains that Yahoo! Mail in the above example hosts in order to construct a mailer table. Luckily, when high-profile mail hubs (like Gmail, Yahoo! Mail and Hotmail) implement good patterns on their DNS MX RRs, a programmatic (instead of a static) solution can be deployed:
LOCAL_CONFIG Kbestmx bestmx -T.TMP LOCAL_RULE_0 R$+ < @ $+ > $* $: $(bestmx $2 $: NOTFOUND $) $| $1 < @ $2 > $3 R$+.hotmail.com. $| $+ < @ $+ > $* $#esmtp $@ [server.example.com] $: $2 < @ $3 > $4 R$+ $| $+ < @ $+ > $* $: $2 < @ $3 > $4
In the above snippet, any email that is directed to a domain that is served by Hotmail’s servers is routed via server.example.com. For the record, our outgoing webmail server achieved a senderscore of 50, and although a filter stopped the plaque, Hotmail silently discarded email originating from it. Using the above solution restored communications for our users.
Using bestmx for discarding outgoing email
2010/07/07
The following ruleset discards email that originates from domains for which we are not best MX. It is meant to be applied on outgoing email servers:
LOCAL_CONFIG Kbestmx bestmx -T.TMP LOCAL_RULESETS SLocal_check_mail R$* $: $>canonify $1 # You may (or may not) want to comment the following line R < @ > $#OK R$* < @ $+. > $* $1 < @ $2 > $3 R$* < @ $+ > $* $: $2 # Short circuit certain domains (and host names) Rexample.com $#OK R$* . example.com $#OK R$* $: $(bestmx $1 $: NO $) # If a temporary error occurs, do not block R$*.TMP $#OK Rserver.example.com. $#OK R$* $#discard $: $1
This works for as long as spammers do not use domains for which they do not control the DNS zones. If they do control the DNS zones they can easily add your relays as MX to them. In such cases the above ruleset must be modified to lookup the name servers for domains that server.example.com is best MX and then decide to discard. However the above trick erased thousands of outgoing spams yesterday.
PS: Like I posted on twitter: I rewrote the above filter in ~35 lines of Perl (subroutine filter_sender for MIMEDefang’s mimedefang-filter). The sendmail version is both more compact and readable (at least to me).
