Older blog entries for cord (starting at number 30)

Debian Lists vs. Mail2News-Gateways.

While analysing the pole setters in our internal bouncers-Hitlist i found that some of them run a mail2news-Gateway.

The problem is: our Mailinglists leave Mail-Headers mostly untouched, and so headers like X-Trace or X-Complaints-To are passed through without modifications.

If a mail containing those headers is handed over to inews (as in INN) it rejects it, and the bounce comes back to us:

<XXXXX@XXX.com>: Command died with status 1: "/usr/bin/maildrop". Command
output: inews: cannot send article to server: 441 Can't set system
"X-Complaints-To" header inews: article not posted

so people: fix your systems. if you do more with listmail than dropping it somewhere make sure that the bounces your system produces go to someone who can fix it. We (as in listmasters) normally simply unsubscribe those.

btw: we talk about 18181 bounces since 08.2004 in this case.

Syndicated 2008-01-14 09:09:06 from Sprachrohr - offizielles Verlautbarungsorgan

Precedence-Mail-Headers?

I'm just wadeing through Debian-Mailinglists on the search for enhancements and false-positives.

and i just came over debian-security-announce, a lists that sends a helpful message back to submitters that aren't allowed to send out advisories.

That message didn't contain a Precedence-Header so i added one, and wondered which value would be appropriate... I remember to have seen three values: 'junk', 'bulk' and 'list' (the latter should be set for all our Mailinglists).

So i tried the usual ways to find out about some more possible values, but i couldn't find a RfC or another Document that describes correct usage of the Precedence-Header.

So, i set the Header to 'junk' now, but if someone could point me to some documentation i would be thankful.

Syndicated 2008-01-02 19:16:11 from Sprachrohr - offizielles Verlautbarungsorgan

Happy New Year, it's 1984 in Germany

http://www.vorratsdatenspeicherung.de/

Syndicated 2007-12-31 23:00:00 from Sprachrohr - offizielles Verlautbarungsorgan

Scratchbox: You must close your other scratchbox sessions first

after playing around a little bit with maemo inside scratchbox, i managed to break the packetsystem beyond repair... so i wanted to start again, but the maemo-sdk-install_4.0.sh told me:

E: You must close your other scratchbox sessions first

so... where to go from here?

http://mg.pov.lt/maemo-irclog/%23maemo. ... 0.log.html knows it:

sb-conf killall

are the magic words. lets start again.

Syndicated 2007-11-10 21:22:40 from Sprachrohr - offizielles Verlautbarungsorgan

Scratchbox: Inconsistency detected by ld.so

As i blogged before i'm going to be the happy (?) owner of a Nokia N810. On this device runs a Linux with a special distribution and there is also a Development SDK, which can be run on ia32-machines.

This SDK relies on Scratchbox, so i just downloaded and tried to install it. This works smoothly, they provide a shellscript, which downloads all needed components and feeds them to dpkg.

But, when i try to start Scratchbox i get

Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!

after some g00gleing, i finally found the solution here: [Scratchbox-users] Re: scratchbox doesn't works any more.

and the answer is: The kernel needs VDSO. This option is in Linux-Kernel-menuconfig in the 'Processor type and features' submenu.

The help on that item shows:

Say N here if you are running a sufficiently recent glibc version (2.3.3 or later), to remove the high-mapped VDSO mapping and to exclusively use the randomized VDSO.

and so i switched it off. Ok, with on again now, lets find the next obstacle.

Syndicated 2007-11-10 08:11:23 from Sprachrohr - offizielles Verlautbarungsorgan

N810 maemo submission accepted

Yes, I just received the following mail:

Congratulations! You have been accepted to the N810 maemo device
program. We will send your discount and instructions as soon as the
device is available in your selected shop (soon).

maemo team - http://maemo.org

So christmas is saved.

Syndicated 2007-11-09 18:02:51 from Sprachrohr - offizielles Verlautbarungsorgan

RIP Telekommunikationsgeheimnis.

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

Syndicated 2007-11-09 13:59:55 from Sprachrohr - offizielles Verlautbarungsorgan

mutt: autoviewing text/html

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...

Syndicated 2007-11-03 13:17:19 from Sprachrohr - offizielles Verlautbarungsorgan

sendmail uses ident be default

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/

Syndicated 2007-09-29 12:52:16 from Sprachrohr - offizielles Verlautbarungsorgan

Analysis of subscribed Domains on Debian-Listserver.

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.

Syndicated 2007-09-14 13:21:40 from Sprachrohr - offizielles Verlautbarungsorgan