Explaination for non German Readers: Today the german parliament passed an act, which orders all communication-connection data (caller-ids, times, email-communication, other internet-transactions) have to be stored for 6 months.

More info on vorratsdatenspeicherung.de

Ich interessiere mich zwar nur selten für das BILDblog, aber angesichts der Umstände spendiere ich hiermit mal einen Link gegen Awarenessblogger.

it sometimes funny, i'm working with mutt since about 10years, (the 5years before i was using elm) and just found out how i can view pure text/html-Mails without fiddeling with piping and things.

set implicit_autoview

in .muttrc does the trick.

but now mutt also prefers the text/html-part of multipart/alternative-mails, this is going to far for me. i want the text/plain-part if available. mutt has also a solution here:

alternative_order text/plain text/html

and done. no more piping to html2text. One day i'll read through the whole manual again...

I have no idea how the other major MTAs handle this, but sendmail seems to issue an ident-auth-request on each connect it gets.

As i think this is rather useless, as most hosts don't answer it, and, even if they would, the answer is easily fakeable, i switched it off.

adding

define(`confTO_IDENT', `0')dnl

to /etc/mail/sendmail.mc disables this. Sadly this isn't documented, for confTO_IDENT it only states

The timeout waiting for a response to an IDENT query.

thanks goes to http://sial.org/howto/sendmail/tips/

addendum: 'Your Name' in the comments is right. ident is still of some use on multiuser-systems to the local admin. But in the field of Internet-mailservers it is useless.

From time to time we have the problem that a mail posted to a list triggers an autoresponse (vacation, bounce, tdma) from an unexpected source. Sometimes it isn't possible to identify the subscriber who is causing this. One example for this was 'petsupermarket'.

So i wrote a small tool, which takes Mailadresses as input and resolves the domains until it reaches IP-level, so it is possible to identify 'related' addresses to such an incident.

I now ran this tool for all 38656 domainparts mailadresses that are currently subscribed to some list at our listservers:

Unresolveable Domains                             :   443
Grounded Domains                                  :     3
Domains with A                                    :  1058
Domains with CNAME, A                             :    59
Domains with CNAME, CNAME, A                      :     3
Domains with MX, A                                : 36202
Domains with MX, CNAME, A                         :  1199
Domains with MX, CNAME, CNAME, A                  :    22
Domains with MX, CNAME, CNAME, CNAME, A           :     5
Domains with MX, PTR                              :    36
Domains with unresolvable Hosts                   :   361

(You may have noticed that those lines doesn't sum up to 38656. It is possible to have more than one MX-Host, and it is also possible to have more than one IP in an A-Record. If one of those combinations falls into another category it is counted twice)

so we have 36528 domains that are completely configured correctly according to RfC 2821 with a MX-Record pointing to an A-Record, or without a MX-Record and an A-Record. These are 94.5% of all domains.

but we have 443 domains in our list, that didn't resolve at the moment i ran my script, those have to be investigated.

We also have 3 domains that are configured with 'IN MX 0 .' as decribed in this expired Draft, those also have to be investigated, and thrown out.

We have 1288 domains, which use CNAMEs (or CNAMEs pointing to CNAMEs) in their MX or directly on their domainname. RFC1034 says:

Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information.

then there are 36 domains which point their MX directly to an IP-Number. RFC 1035 says:

3.3.9. MX RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                  PREFERENCE                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   EXCHANGE                    /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

PREFERENCE      A 16 bit integer which specifies the preference given to
                this RR among others at the same owner.  Lower values
                are preferred.

EXCHANGE        A <domain-name> which specifies a host willing to act as
                a mail exchange for the owner name.

MX records cause type A additional section processing for the host
specified by EXCHANGE.

So according to that an MX has to point explicitely to a Full Qualified Domain Name, and it has to be an A-Record it points to.

However: Most MTAs (including ours) these days forgive this, and figure out the right thing.

At last: we have 361 Domains which MX and/or CNAME-Records point to Hostnames that are currently unresolvable. A quick check shows that often the problems only appear on one MX-Record, while another is correct, so the service is functional.

So maybe now it is a good idea and check your own DNS-Setup and the Mail-related Data.