Archive, Activity?

Questioning Log file directory structure

Erratic server bouncing mail

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

Re: October 79% OFF

Effective as from 1st December 2004 our email address has changed to info <at> portdouglasbeachfront.com.au

Complete Archive?

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

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

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
>

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.

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 12:39:22AM +0100, David Sanchez wrote:
> > The proposal of captcha as we are doing here involves at least 3 mails
> > per transaction (the mail itself, the challenge and the response).
>
> I think the proposal was to integrate captcha within the SMTP exchange
> itself, so no extra mails are generated.
>
> However, when you consider the normal E-mail arrangement:
>
>   UA1 ----> relay1 -------------------> MX2 ----> UA2
>
> then observe that the protocol as discussed:
>
> (1) needs to run on a different port to SMTP (because it requires direct
>     communication between UA1 and MX2, and many sites block this)
> (2) involves a completely new set of SMTP primitives
> (3) requires UA1 to perform its own MX lookups, direct mail delivery,
>     per-message queueing and retry, none of which is currently needed
>     because it offloads all that work to relay1
>
> In other words, what you end up with is pretty much nothing like SMTP.

Ok, so transition will be a mess 

> > The solution of a lot of mail problems should pass adopting the IM2000
> > proposal of being the sender who stores the mail.
>
> I don't think that makes much difference in this case.
>
> The fundamental problem which arises is:
>
> * I've got notification that someone wants to send me a message
>   (whether that be an incoming SMTP connection, an IM2000 'notify',
>   an inbound IM or whatever)
>
> * How can I, or the message protocol itself, distinguish between a mail I
>   want and spam?
>
> This is an extremely hard problem, given that:
>
> (a) not everyone agrees on what is or is not spam; and
> (b) any widely-used tests for "spamminess" become known by the spammers,
>     and they change their mail-sending habits to get around them
>
> [The 'captcha' proposal tries to distinguish spam and non-spam by requiring
> an intelligent response to each message, on the assumption that this doesn't
> scale for spammers who want to send millions of messages. However spammers
> can quite happily make captchas scale, by redirecting them to users who are
> trying to get access to porn sites, for example, and they are already doing
> this on a large scale]
>
> Personally, with the vast amounts of spam I get, I'm thinking that I'd be
> happy to move to a completely 'closed' E-mail system where only people I
> know in advance can contact me directly. I might lose some intelligent and
> interesting communication with strangers, but I wouldn't have to worry about
> losing mails from friends because they are misclassified as spam. I can
> still participate in public discussion via web BBSes.
>
> So what I want is basically a combination of sender proving their identity,
> plus a whitelist of senders personally known to me.
>
> The problem is how to do identity proving. Possible solutions:
>
> - your friends all use GPG or s/MIME signatures (unlikely to happen,
>   unless all your friends are uber-nerds)
>
> - IM2000 gives a pretty good identity assurance for free, but nobody uses it
>
> - DomainKeys isn't much good, as any assurance it gives only works at the
>   domain level, not the mailbox [unless ISPs are required to use SMTP AUTH
>   for all mail submissions]
>
> - I could set up a web-based BBS, and all my friends would have to create
>   accounts on it to post private mail to me. This doesn't scale, because
>   I'd need separate accounts on every BBS for every friend, and would have
>   lots of BBSes to check for new mail.
>
> - BBS postings could be validated via browser client certificates. This
>   scales, but isn't very useful - e.g. if you're out in a cybercafe you
>   are unlikely to have brought your client certificate with you, and even
>   if you did, you wouldn't want to install it in a cybercafe PC.
>
> - Mail (or BBS postings) could be submitted via some centralised
>   identity-proving system like Passport, which in turn signs the mail.
>   That, to me, sounds like a pretty good solution. You can have multiple
>   identity brokers, like you have multiple CAs, and trust which ones you
>   want. The difference is that your identity lives on a central server,
>   and you activate it on demand (e.g. with username and password) to
>   authenticate a particular session or message. Hence it can be used in
>   roaming applications, and doesn't require you to get involved with key
>   or certificate management at the client side.
>
> [This approach would be very nice for public BBS participation too, as I
> wouldn't have to register on each BBS individually]
>
> 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.

Internet Mail spam could be more or less avoided with SPF and, at option,
domainkeys and per user filters.

That's the only way, IMHO, with current infraestructure without
loosing any functionality

Future solutions will be all IM be integrated seemlessly (say, Jabber
protocol), but how can anyone enforce integration? :-P

> Regards,
>
> Brian.
>