FLoh Leeber | 21 Apr 14:51 2011
Picon

Archive, Activity?

Dear all,
 
I was not able to find any archive of this list, so I just wanted to know, is there activity here and also some kind of archive online?
 
regards FL
 
Adam Smith | 18 Apr 05:01 2009
Picon

Questioning Log file directory structure

Hello,

I seem to have a problem, I believe. Would someone say if my log file
(s) structure seem correct? I am using a LWQ installation on a FreeBSD
O/S vers 6.0 platform

# ls /var/log/qmail/
./                               <at> 4000000049e70cd92ced5d9c.s
../                             <at> 4000000049e711ec05b7573c.s
<at> 4000000049e6ee5e2dd521a4.s     <at> 4000000049e716fe15c63224.s
<at> 4000000049e6f3710423d65c.s    current
<at> 4000000049e6f88316b0c104.s    lock
<at> 4000000049e6fd952874c9e4.s    pop3d/
<at> 4000000049e702a8034380ac.s    smtpd/
<at> 4000000049e707c713de3c2c.s    state

# ls /var/log/qmail/smtpd
./                               <at> 4000000049e68b9217a0b2cc.s
../                             <at> 4000000049e6b522363cc9dc.s
<at> 4000000049e5dd8738edb13c.s     <at> 4000000049e6e6ea04e6e00c.s
<at> 4000000049e5fd49374c3a24.s     <at> 4000000049e6f70f04b72164.s
<at> 4000000049e61f10254f3f24.s    current
<at> 4000000049e63887247b2644.s    lock
<at> 4000000049e663dd1fa6ca74.s    state

# ls /var/log/qmail/pop3d/
./                               <at> 4000000049e568751eabd844.s
../                             <at> 4000000049e60ecc0815ec64.s
<at> 4000000049dd3ceb1d2f32f4.s     <at> 4000000049e64e5d29e5c6d4.s
<at> 4000000049e4251a07b1c7ac.s     <at> 4000000049e684590cb2c15c.s
<at> 4000000049e4b847274692b4.s    current
<at> 4000000049e4ebd7359556ac.s    lock
<at> 4000000049e532282ef4689c.s    state


I wanted to look at my qmail-send log

I was expecting to see the log file -
/var/log/qmail/service/

and running
# /service/qmail-send/log/run       =>
multilog: fatal: unable to lock directory /var/log/qmail: temporary
failure

Adam Smith | 18 Apr 05:07 2009
Picon

Erratic server bouncing mail

Hello,

I  have a problem with my mail server being erratic intermittently
I am using a LWQ installation on a FreeBSD O/S vers 6.0 platform

some mail sent to clients on the system gets bounced back to sender. This may be correlated, I DO NOT KNOW, with attempts to send mail and the system replies with a failure message, e.g. smtp not found, but frequently after 2 or 3 attempts, there might be a success.

TY
--  Adam  --
______________________________________________________________________

Antone Roundy | 18 Dec 15:52 2008
Picon

New subscriber has questions

Hi all,

Just subscribed yesterday, and I have a few questions:

* Is this mailing list active?

* Are there any existing implementations on IM2000?

* If so, how many users does it have?

* If "nothing in the recipient notification that reaches the recipient 
MUA is directly specified as part of the message by the message 
originator", how does the recipient determine whether to request message 
headers or the entire message? If requesting "summary headers" is the 
answer, then how is that superior to including the summary headers in 
the notification (and perhaps imposing hard limits on how much data that 
can include)?

* If the "no headers in the notification" concept sticks, will it be 
possible to request summary headers over the existing connection when 
receiving a notification? (If you're going to request summary headers 
for every message anyway, which I imagine many will, it would be nice to 
be able to avoid the overhead of setting up another connection every 
time to do it).

* Going a little farther than the previous, would it be possible to 
automatically request the entire message over the notification 
connection (which you'd only do from known trusted senders of course)?

* When requesting summary headers or entire messages, can the requesting 
software indicate in its request that it's an automated request vs. a 
request made in response to a user action (so that the sender will be 
able to tell the difference between their message having been read...or 
at least noticed and downloaded intentionally...and having simple been 
retrieved but perhaps not seen by human eyes)?

* Can a message sender indicate an expiration time after which the 
message will be deleted from their store?  (If so, I'd suggest the 
timestamp be TRANSMITTED as "seconds from now" to avoid ambiguity over 
timezones or computers with their clocks set wrong.)

* If the spam-deterrent built in to IM2000 is based on shifting costs to 
senders, is it expected that the STORAGE cost would provide sufficient 
deterrent, or that the storage + DELIVERY cost would be the deterrent. 
It seems to me that storage costs alone might not be much deterrent -- 
after all, you could store one message and send 10 billion notifications 
about it. You could even use different message IDs for each recipient 
but have some way to tell that they're the same message (eg. start all 
of the IDs with "1234567890" and tack on "asdf" for one recipient, 
"qwerty" for another, etc.

* Is there a provision for requesting something like a captcha in order 
to get greylisted and get your notifications delievered?

I'm feeling the pain of SMTP right now, so I've got a little fire in my 
belly, and the only cure is more cowbell...er, replacing SMTP:

http://antone.geckotribe.com/alpha-gecko/anybody-wanna-join-me-in-a-day-without-email-smtp/

Antone Roundy

Mike Moore | 18 Dec 12:36 2006

Complete Archive?

How do I get to (at least) the subject lines of past messages… I know I can get a message number, but how many messages are there and what were they about?

 

Mike

 

Brett Watson | 5 Dec 05:16 2006
Picon

Monetary bonds in email

Subject was "CAPTCHA over smtp (yet another spam solution to discuss)".

On 12/5/06, Joachim Kupke <joachim <at> kupke.za.net> wrote:
> Let's assume everybody turns their filters off.
> Let's assume everybody receives 1ยข per spam message (if claimed).
> Somebody will have to pay for it.
>
> You are saying:  Spammers could abuse credit cards to an extent
> necessary to spend this kind of money.
>
> No numbers, but if you can squeeze that much money out of stolen credit
> cards, you probably won't have to "work" (be it as a spammer) anymore.

The "one cent per spam message (if claimed)" is a "bond": a monetary
promise that certain conditions will be met, with forfeiture of the
bond as the cost of non-compliance.

Where a blackhat has access to illicit credit card details, spam was
probably involved in the process of obtaining those details in the
first place. A blackhat has two broad ways of obtaining such details:
buy them on the black market, or obtain them himself. In the former
case, he's just paying someone else to do the latter, so let's
concentrate on the latter case.

There are several obvious ways that one can obtain CC details.

1. Phishing. Send spam which claims to be from a particular bank,
claiming that the user must reactivate his Internet banking facility.
Provide a web page with forms covering the gamut from account number
to credit card number, to mother's maiden name, PINs and passwords.

2. A shop. Set up an Internet shop front selling cheap pharmaceuticals
or imitation watches. Advertise via spam. Don't actually hold any
stock or make any deliveries -- just allow people to order, disclosing
their CC# and verification codes, then apologise that the transaction
could not be processed for some reason. (E.g.: "Our payment processing
facility is down, please try again tomorrow.")

3. Keystroke logging. Send spam which points people to a website
loaded with an exploit which installs a keylogger on their system.
Harvest every useful piece of information, such as eBay and PayPal
login details, Internet banking details, email addresses for further
spamming, and, of course, credit card details.

4. Hack a payment processor or online shop directly. Raid the database
or install a back door.

Of these options, only #4 does not involve spamming as a part of the
process. If the cost of spamming goes up, then the expected return on
investment goes down, but so long as it remains a grossly profitable
exercise, there is incentive to continue. Crime is a high risk, high
margin business.

But even this analysis overlooks the obvious. Let's make the
assumptions you cite about every email being covered by a one cent
bond which the recipient may claim if he considers the message spam.
This creates a new form of currency in the spammer world: compromised
email accounts.

Just as Internet banking account access credentials are bought and
sold on the black market now, new specialists will arise who sell
compromised email accounts. An account with $X worth of "stamp credit"
in it will probably cash out on the black market for a small
percentage of that amount. It competes against the process of setting
up a new Yahoo!/Hotmail not-quite-free-anymore email account with $X
in credit from a stolen credit card.

There's also the question of how easily a certain activity can be
"cashed out", or converted into something of value. If you have a
credit card number, then you can attempt to purchase goods and have
them shipped to you, or you can purchase intangibles like a domain
name and email credit. In the latter case, you can start using the
goods instantly, before anyone has a chance to detect the fraud. It's
much easier to "cash out" that way, and thus an attractive form of
fraud.

In short, I don't think that the "bonded sender" style of anti-spam
can work, even in principle, because spam has changed. Whereas before
we were hit primarily by junk from "legitimate" businesses who saw
spam as a very cheap means of advertising, the larger source is now
the hard-core scammers and criminals who see it as a safe way to
conduct extremely profitable crimes. It's not clear that we can defeat
this crowd with economic pressure, because they don't play by the
rules. If something is too expensive for them, they steal it instead
of buying it. The economics of crime and the economics of commerce are
different things.

Making email a more expensive thing simply makes it a more attractive
target of theft. Cybercrooks have little incentive to hack your email
account when they can set up new free accounts easily, or just
generate spam directly. Make your email account valuable, however, and
they may decide that it's easier to steal yours than start a new one.

Joachim Kupke | 17 Nov 06:46 2006
Picon

Re: CAPTCHA over smtp (yet another spam solution to discuss)

I hope you don't mind if we take this back to the list?

Brett Watson wrote:

>On 11/17/06, Joachim Kupke <joachim <at> kupke.za.net> wrote:
>>However, the "transfer" in that suggests there may be a chain of them.  
>>I take exception to the claim that there is a fundamental need to 
>>chain MTAs.
>
>Mailing lists, for one reason.

These would go away.  To avoid confusion, they would be replaced by 
ordinary mailboxes with read-only IMAP access or RSS or whatever.  The 
mailing list administrator makes the decision who gets to post.  Either 
by whitelisting, or by requiring captchas solved, or by requiring a 
security deposit.  The latter has the benefit that they could seize the 
bond and reimburse subscribers.

>Mail forwarding of any sort, in fact.  In the general case, these 
>result in MTA chaining because they result in address re-writing.

Think web proxying rather than mail forwarding.  Or, more generally, 
nesting one request inside the other.
(In fact, what do you do, as an MX administrator, in a situation like 
this:  For two domains X and Y, all addresses user <at> X should be rewritten 
to user <at> Y.  Y's MX is not under your control and won't accept X as an 
rcpthost.  You have a service on X's MX[es] running that services SMTP 
requests and, while processing them, opens another SMTP connection to 
Y's MX, with the envelope address rewritten properly [and 251 reply 
codes output].)

>There are other reasons, but these are the obvious cases.

What are the non-obvious ones?

>> >I meant, greylisting is not related with im2000.
>>
>>But it is.  It is a clunky implementation of it, although mostly 
>>backwards-compatible with SMTP.
>
>Greylisting is an implementation of IM2000 in the same way that a 
>web-forum is an implementation of IM2000 -- i.e. only under a 
>too-liberal interpretation of "is an implementation". In my opinion, to 
>be similar to IM2000 in any significant sense requires that the 
>recipients be in a position to pull the message on demand. Greylisting 
>does not offer that.

How, precisely, is the spam problem mitigated if pulling messages 
happens "on demand" as opposed to "nearly on demand" (i.e., refuse to 
accept a message and say "maybe later" instead)?

[How do people adopt completely new protocols?]
>>Ah, I see.  Get a critical mass to adopt it.  If you can't do that, 
>>you can roll out neither "clean" IM2000 nor captcha-SMTP nor 
>>general-purpose C/R email nor anything.
>
>Not everything requires a critical mass of early adopters. Greylisting 
>can be applied unilaterally, and I'm not sure why you claim that 
>general-purpose C/R requires critical mass, since I've received C/R 
>challenges without myself being an adopter.

The question was how to deal with users' reluctance to switch to a new 
system as illustrated by the de-facto abandonment of IPv6.  If OpenPGP 
were a widely-used message format, in the sense that a critical mass had 
been surpassed, we would be seeing the vast majority of new email users 
create crypto keys before they send their first message.  That's how you 
tell whether a mass is criticial; it's a tautology.  You can still be 
backward-compatible, as in the IPv6 case, and as with C/R applications 
over traditional email.

>CAPTCHA-enabled SMTP seems to me to miss the point of SMTP entirely.  
>SMTP is a machine to machine protocol, and introducing CAPTCHAs into it 
>utterly defeats that design.

It's really captcha-over-mail-injection-on-the-recipient's-side.

>Those who are keen on CAPTCHAs would seem to me to be far better off 
>doing it this way.
[Protecting access to a whitelist rather than the individual message.]

For the record; whether you were to use captchas or financial bonds, 
your comments apply equally:  You would end up protecting your 
whitelist.  Unfortunately, sender addresses are easy to forge (as you 
know); and unfortunately, the occasional email-contact-turned-spammer is 
not unheard of.

>It's better than the CAPTCHA-in-SMTP thing, however, which just Ain't 
>Going to Happen.

It relies on the assumption of a constant reputability of senders.  
C/R-in-SMTP, indeed, means reengineering large parts of how the Internet 
works.

--Joachim

Joachim Kupke | 14 Nov 01:34 2006
Picon

Re: CAPTCHA over smtp (yet another spam solution to discuss)

David Sanchez wrote:

>>Ah, mailing lists.  Nope, the mailing list would prompt you to solve 
>>the puzzle.  Or pay the money or whatever.
>
>Nope, i mean sending a mail with copy to 3 or 4 people.
>
>This is just impracticable.

Are you saying:  You would like to send out a message to 4 people, some 
of whom speak Chinese and will therefore ask you to solve a puzzle 
stated in Chinese, and others speak Italian and will therefore ask you 
to solve a puzzle states in Italian?

Plus, these folks didn't whitelist you to begin with?

Are you spamming them?

>>If you need an output queue, go get your own.  Don't force everyone 
>>(like SMTP does) to think in terms of there being an output queue all 
>>the time.
>
>If output queue is just an option, why don't just use a phone call or 
>IM?  :-P

Because I would need to hook up my modem to the phone in order to 
transmit, conveniently, arbitrary data.

Instant Messaging is just email in disguise.

>For me is a must, mail without delay delivering is not mail. Is just 
>another thing.

If that other thing serves everybody's purposes (but yours) just as well 
as email does, only without the spam, that'd be great.

>Yeah, i'll send you a blackmail (which is spam, by definition)

Would like to see that definition.  Blackmailing people is most likely 
to be criminal, though.

>and perfectly fill the Challenge offered by your MTA, and pay whatever 
>it costs.

What---you'd pay me $1M in order to convey threatening words to my 
computer screen?  Deal.

Seriously, as soon as the cost of sending any message (even a criminal 
one) to my virtual doorstep exceeds that of sending it, via express 
courier or in person, to my physical doorstep, the spam problem is 
pretty much solved.

>That's an example of unavoidable spam.

Your definition of spam might go something along the lines of, anything 
that doesn't make you happy.  Other people might want, for good reason, 
to read messages that don't make them happy.

>If you want whole internet availability you must deal with spam. Simple as 
>that.
>
>Moreover the idea of paying for sending is against current Internet 
>philosophy.

You may want to give evidence for these claims.

>I will just quit using, developing or maintaining a service in that 
>paying is a MUST. Simple as that.

Never sent old-style mail, using postage?  (To regurgitate, reimbursing 
recipients for their attention span is NOT postage.)

>Not likely to happen, thank god.
>
>Another example, i do have a lot of spam in my phisical mailbox, and 
>that traditionally had costs (stamps, the deliver guy, etc...). And 
>spam in your car front when parked. And all that had implied costs (a 
>lot more than electronic communications).

Advertisers advertise because it increases their revenue.  Nobody is 
banning the ads business.  Spam, by my definition, is the process of 
sending a person mail at an expense (to them) that exceeds the utility 
of that piece of mail.  A commercial on TV doesn't qualify because it 
pays for your TV show.  Spam in your physical mailbox exists precisely 
because (I'm pretty sure) it's free for me to put anything into it.

Again, we are not talking about postage.

>> >The solution of a lot of mail problems should pass adopting the 
>> >IM2000 proposal of being the sender who stores the mail.
>>
>>I think this reasoning has already been found to be flawed.  Hell, 
>>greylisting would be superior to IM2000 if it weren't for the need for 
>>senders' busy-waiting.
>
>Maybe it's true, but spam and other mail problems will be disminished.

Another claim you may want to give evidence for.

>If you want a universal, free access internet mail, spam is unavoidable

Oops; you just said that "whole Internet availability" already resulted 
in spam.  Now you are adding "free access" to the equation.  So, do you 
agree that availability across the whole Internet is *not* a problem?  
(If so, we can work on "free access" not being a problem, either.)

--Joachim

David Sanchez | 13 Nov 22:27 2006

RE: CAPTCHA over smtp (yet another spam solution to discuss)

> You may be saying that connecting the web and email is difficult,
> although I don't see what exactly you may be alluding to.  Connecting
> HTTP and email is simple; spammers do this all the time when they
> exploit publicly-accessible HTTP proxies and send out what looks like a
> legitimate HTTP proxy request but is actually (after a few
> error-triggering commands) translated to (more-or-less) valid SMTP.

I was only rebating about cookies and http and the like.

IMHO that was a mess.

>
> >I do not see this clearly, sorry
> >
> >> >3.- i18n, for example, if one of my users sends a message to a user
> >> >in an american domain for example, the american MTA will send him a
> >> >captcha message in English, which is likely  to be discarded as spam
> >> >for my users, or simply don't understood (bounces in current
> >> >infraestructure is a good real world example)
> >>
> >>A valid point, but you're optimizing prematurely.  People who speak
> >>only one (natural) language themselves will just configure their MUA
> >>to ask the equivalent of "please solve this puzzle" in their native
> >>language.  If I send a Spanish message to a person who asks me to
> >>solve a puzzle stated in Chinese, that just makes the puzzle the more
> >>entertaining for a non-speaker of Chinese. ;-)
> >
> >mmmh i thought was the MTA who was sending the challenge not MUA!
>
> Yep, sorry, I was envisioning a means of configuring the MTA's
> challenging behavior, probably by using some sort of a configuration
> dialog that you would pull up in your MUA, though.
>
> >I don't get you anyway.
> >
> >When i write a mail to, say, a workgroup of 30 people I don't want to
> >resolve 30 chinese, japanese, swahili nor portuguese puzzles anyway.
>
> Ah, mailing lists.  Nope, the mailing list would prompt you to solve the
> puzzle.  Or pay the money or whatever.

Nope, i mean sending a mail with copy to 3 or 4 people.

This is just impracticable.

> >> >2.- As a consecuence, a new world of DoS is open  :-(   (a spammer
> >> >for example can make a mail server to generate continues captcha
> >> >mails, which is resouce consuming)
> >>
> >>Doesn't sound like a huge problem, though.  How is this different from
> >>captcha systems that try to avoid web spam?
> >
> >Simple, web spam is a passive system, they usually offer the challenge
> >in the same transaction you use to send the web form (that mighty fuzzy
> >characters image for example:
> >https://www.nic.es/esnic/esn/verValidacionWhoisAction?dominio=nic.es
> >).
> >
> >The proposal of captcha as we are doing here involves at least 3 mails
> >per transaction (the mail itself, the challenge and the response).
>
> No; three messages but one email.  Here's the scenario:
>
> You compose your message, and let's assume the recipient doesn't know
> you yet.  Your MUA figures out (by querying DNS) whether the recipient
> supports the protocol.  If so, it refrains from sending your message via
> SMTP, but rather, behind the scenes, it goes to a standardized web page
> (or some equivalent of that) that has a huge textarea where it deposits
> the message, clicks the "send" button and figures out how to resolve
> what comes next.  It's unclear whether there should be a bound on the
> number of challenge/response rounds.
>
> >>True, but forcing the MUA to maintain the remote queue is a better
> >>choice, anyway.  Although it deviates from tradition, this would make
> >>it obvious to the user if/which messages are stuck.
> >
> >Think about this situation:
> >
> >Friday 7:00 PM:
> >
> >You must send an e-mail to client before monday comes and his mail
> >server provider is in maintenance or has connectivity problems.
> >
> >Would you stay in office with your PC and your, say, Outlook opened
> >waiting for the mail to be delivered?
> >
> >A plain old 26 year old SMTP protocol MTA just would accept the message
> >and keep trying sending the mail. (your MTA relay don't sleep and has
> >no social life anyway :-P )
>
> Neither does the PC that runs the MUA.  There are really two
> sub-situations, here.  Either, that email is important enough for me to
> watch it getting sent out.  (Given what email is like today, I might
> actually log into the MX and watch qmail-remote send my message, in such
> a case.)  Or, as with this message, lives won't necessarily be lost if I
> fail to reply to qsecretary as soon as possible.
>
> In the former case, I might as well want to have qmail-remote's
> functionality integrated in my MUA.  In the latter case, if I'm not
> willing to leave my PC turned on (or online---think a mobile device),
> there may be a need for an output queue on a different machine, yes.
>
> If you need an output queue, go get your own.  Don't force everyone
> (like SMTP does) to think in terms of there being an output queue all
> the time.

If output queue is just an option, why don't just use a phone call or IM? :-P

For me is a must, mail without delay delivering is not mail. Is just
another thing.

> Spam is entirely avoidable (albeit the collateral damage would be
> substantial) if you make senders pay for their messages.  Ideally, by
> posting a bond that may be seized by the recipient if they classify the
> message as spam.  Now, in order for the recipient to announce the
> minimal value of such a bond (how much their attention span is worth, in
> other words) and in order for both parties to agree on what constitutes
> a(n electronic) bond---a credit card number is a bad idea---you need
> quite a lot of C/R no matter what.  An email protocol, unlike SMTP,
> should support this.

Yeah, i'll send you a blackmail (which is spam, by definition) and
perfectly fill the Challenge offered by your MTA, and pay whatever it
costs.

That's an example of unavoidable spam.

If you want whole internet availability you must deal with spam. Simple as that.

Moreover the idea of paying for sending is against current Internet philosophy.

I will just quit using, developing or maintaining a service in that
paying is a MUST. Simple as that.

Not likely to happen, thank god.

Another example, i do have a lot of spam in my phisical mailbox, and
that traditionally had costs (stamps, the deliver guy, etc...). And
spam in your car front when parked. And all that had implied costs (a
lot more than electronic communications).

> >The solution of a lot of mail problems should pass adopting the IM2000
> >proposal of being the sender who stores the mail.
>
> I think this reasoning has already been found to be flawed.  Hell,
> greylisting would be superior to IM2000 if it weren't for the need for
> senders' busy-waiting.

Maybe it's true, but spam and other mail problems will be disminished.

If you want a universal, free access internet mail, spam is unavoidable

>
> --Joachim
>

Brian Candler | 11 Nov 16:27 2006
Picon

Re: CAPTCHA over smtp (yet another spam solution to discuss)

On Sat, Nov 11, 2006 at 03:37:25PM +0100, David Sanchez wrote:
> >Now, this last setup is in some ways quite similar to Instant Messanger
> >apps, except that if you want to communicate with everyone on IM then you
> >need your own accounts on every IM system. Also, I'd have to add friend
> >identities manually, to avoid the pop-up messages saying "XXX would like to
> >add you to their contacts, is that OK?", i.e. Spim.
> 
> IM spam could be more or less avoided with SPF and, at option,
> domainkeys and per user filters.

I don't see the logic. I mean, it probably differs between the
implementation of different IM systems, but in the simple case every client
connects to a central server [farm], and authenticates, before sending a
message which is relayed to the other user.

Therefore if I get a message saying

   "User 'foo_wombat_example' wants to make you their buddy"

and this message came from the server, then I'm quite happy that this person
really *is* a user who registered as foo_wombat_example on the IM system.

The question is, is this a spammer, or someone I want to talk to? Should I
accept the buddy request or not?

Regards,

Brian.

David Sanchez | 11 Nov 16:44 2006

Re: CAPTCHA over smtp (yet another spam solution to discuss)

2006/11/11, Brian Candler <B.Candler <at> pobox.com>:
> On Sat, Nov 11, 2006 at 03:37:25PM +0100, David Sanchez wrote:
> > >Now, this last setup is in some ways quite similar to Instant Messanger
> > >apps, except that if you want to communicate with everyone on IM then you
> > >need your own accounts on every IM system. Also, I'd have to add friend
> > >identities manually, to avoid the pop-up messages saying "XXX would like to
> > >add you to their contacts, is that OK?", i.e. Spim.
> >
> > IM spam could be more or less avoided with SPF and, at option,
> > domainkeys and per user filters.
>
> I don't see the logic. I mean, it probably differs between the
> implementation of different IM systems, but in the simple case every client
> connects to a central server [farm], and authenticates, before sending a
> message which is relayed to the other user.
>
> Therefore if I get a message saying
>
>    "User 'foo_wombat_example' wants to make you their buddy"
>
> and this message came from the server, then I'm quite happy that this person
> really *is* a user who registered as foo_wombat_example on the IM system.
>
> The question is, is this a spammer, or someone I want to talk to? Should I
> accept the buddy request or not?

Sorry, "IM" was a typo, i was talking about IM (internet mail), not IM
(instant messenging). (To the best of my knowledge domainkeys and SPF
don't apply to IM ). Sorry again for confusing terms.

BTW: a big step forward of IM  (this time Instant Messenging :-P ) is
that lists of blocked and admited. Moreover you said IM is centralized
worldwide. Maybe for private IM but not for XMPP
(http://www.xmpp.org/specs/rfc3921.html) also known as Jabber. Each
domain has its own users, it's responsible of what their users do, and
communicate with other domains via a well known protocol (see for
example david <at> davidsm.com can comunicate with davidrepking <at> gmail.com.
gmail.com <-> davidsm.com communication is seamless between both
domains providers via Jabber/XMPP)

But the question is, how could you enforce MSN, AOL or Yahoo! enter
the XMPP protocol?

> Regards,
>
> Brian.
>


Gmane