Re: Spam on this list
* Henning Makholm: I find these recurring threads slightly surreal. I think that lists.d.o does a excellent job of filtering spam; my own (anecdotal, non-scientific) experience is that I spend more time reading discussions about how to spamfilter l.d.o better than I spend ignoring spam on the lists. Indeed, I completely agree with you. Spam filtering on the mailing lists is excellent, and the filters do not delay messages at all. I wanted to mention this in my message as well, but forgot to do so. My main concern with BTS filters (latency, accuracy seems to be mostly fine) is being dealt with, apparently. Response time went down noticeably over the past few days. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
On Mon, Sep 05, 2005 at 09:00:36PM +0200, Jesús M. Navarro wrote: Hi, Wouter: El Lunes, 05 Septiembre 2005 19:52, Wouter Verhelst escribió: [...] spam, as in, unsolicited bulk email, was named after a particular brand of corned beef. See http://www.spam.com/ Not exactly. Spam, as unsolicited bulk email, was named after a particular Monty Python's Flying Circus show. It is Monty Python the ones that used spam after the canned meat. It might probe to be a significant difference if held in court. Well, yeah; I read the story on the spam site, too. The point is that the origin of the 'spam' name is corned beef, even if indirectly. I couldn't care less what lawyers have to say about it. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
On Tue, Sep 06, 2005 at 11:07:34AM +0200, Wouter Verhelst wrote: On Mon, Sep 05, 2005 at 09:00:36PM +0200, Jesús M. Navarro wrote: Hi, Wouter: El Lunes, 05 Septiembre 2005 19:52, Wouter Verhelst escribió: [...] spam, as in, unsolicited bulk email, was named after a particular brand of corned beef. See http://www.spam.com/ Not exactly. Spam, as unsolicited bulk email, was named after a particular Monty Python's Flying Circus show. It is Monty Python the ones that used spam after the canned meat. It might probe to be a significant difference if held in court. Well, yeah; I read the story on the spam site, too. The point is that the origin of the 'spam' name is corned beef, even if indirectly. I think you mean spiced ham... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
RE: Spam on the List
I have a question about the general lists; not the bug tracker. What would happen if we can change the policy of the lists (debian-boot, debian-devel, and so forth) so that they will not accept email except from those people who have already subscribed and have confirmed? I belong to some email lists (these are not Debian related, but for social groups) that prohibit any email from getting through to the list recipients except from those who have subscribe and have been confirmed. I have seen far less spam on those because of that policy. Unfortunately, I don't know for sure what those lists use. I have a vague idea that one of them uses something called Mailman and the other uses something called Majordomo. Truly, Mark Allyn
Re: Spam on the List
On 9/6/05, Allyn, MarkX A [EMAIL PROTECTED] wrote: I have a question about the general lists; not the bug tracker. What would happen if we can change the policy of the lists (debian-boot, debian-devel, and so forth) so that they will not accept email except from those people who have already subscribed and have confirmed? I belong to some email lists (these are not Debian related, but for social groups) that prohibit any email from getting through to the list recipients except from those who have subscribe and have been confirmed. I have seen far less spam on those because of that policy. It'd require users to subscribe which may not be desired either.
Re: Spam on the List
* MarkX A. Allyn: What would happen if we can change the policy of the lists (debian-boot, debian-devel, and so forth) so that they will not accept email except from those people who have already subscribed and have confirmed? For some general lists which are Cc:ed regularly (debian-devel, debian-legal, maybe even debian-security), this sounds like a bad idea. You also would have to do this at the SMTP level, see: http://www.enyo.de/fw/software/exim/mailman-smtp-reject.html I don't know how easy this is possible with Smartlist (it's a bit difficult for Exim, too, mainly because of the permission problem). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the List
[MarkX A Allyn] What would happen if we can change the policy of the lists (debian-boot, debian-devel, and so forth) so that they will not accept email except from those people who have already subscribed and have confirmed? Is this a retorical question? A lot of spam and non-spam messages would be rejected. We could send such emails for approval by some list administrator, but this would put quite a load on these administrators (unless someone fix #292929). I would prefer this option myself, but I would not get the extra work. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS (was: Spam on this list)
Hello Blars, Blars Blarson [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Blars Blarson [EMAIL PROTECTED] wrote: I've been working on the spam filtering for the BTS. We are getting over 100,000 spams/day and about 50/day get through the filters. Do you tried bogofilter No or the like? Depends how like you consider spamassassin's bayes filters, which are used. No, I thought of crm114, dbacl and qsf. I use bogofilter and I'm overwhelmed by its detection rate and I can't complain of the speed, as many people do of spamassassin. Which mail server do you use? Exim? Would it be acceptable to reject or drop more non-spam? Drop not, but reject. It would be the best, if you can reject spam in the SMTP dialog. This would take cooperation from debian-admin. Does this mean you drop spam, currently? Regards, Jörg. -- Gienger's Law (http://www.bruhaha.de/laws.html): Die Wichtigkeit eines Newspostings im Usenet ist reziprok zur Anzahl der enthaltenenen, kumulierten Ausrufungszeichen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS (was: Spam on this list)
On Tue, 06 Sep 2005, Joerg Sommer wrote: Does this mean you drop spam, currently? No, we pack it in neat little mailboxes with the greatest of care, and then proceed to blissfully forget that those messages were ever received unless someone wonders why their message never made it through. Then, if someone is feeling magnanimous, they might check through the gigabytes of spam that the BTS has collected to see what exactly happened to the little message that got lost... assuming the wondering query made it through their own personal spam filter... Don Armstrong -- Three little words. (In decending order of importance.) I love you -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Spam on this list
Scripsit Allyn, MarkX A [EMAIL PROTECTED] I have been noticing (and a bit irritated) at the spam I am seeing on this and some other email lists. The latest was a bit offensive for me in my work environment. I find these recurring threads slightly surreal. I think that lists.d.o does a excellent job of filtering spam; my own (anecdotal, non-scientific) experience is that I spend more time reading discussions about how to spamfilter l.d.o better than I spend ignoring spam on the lists. Given that I *don't* do any local filtering of incoming list mail, I'm rather puzzled... -- Henning Makholm ... a specialist in the breakaway oxidation phenomena of certain nuclear reactors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
Am 2005-09-01 20:20:39, schrieb Petter Reinholdtsen: [Allyn, MarkX A] I have been noticing (and a bit irritated) at the spam I am seeing on this and some other email lists. The latest was a bit offensive for me in my work environment. The debian lists are not doing a great job in blocking spam. You Are you happy ? If the SPAM-Filter of Debian fails, you will shot yourself... I think, the filter trash around 99% of the SPAM. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Spam on this list
Michelle Konzack [EMAIL PROTECTED] wrote: If the SPAM-Filter of Debian fails, you will shot yourself... I think, the filter trash around 99% of the SPAM. That should be spam - SPAM is a trademark of Hormel Foods Corporation. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
[Michelle Konzack] Are you happy ? Sure, I am happy. :) If the SPAM-Filter of Debian fails, you will shot yourself... I think, the filter trash around 99% of the SPAM. I will? I do not know if gmane uses the debian spamfilters, but it seem to do quite a good job filtering out spam. :) I wish the debian mail server would do an equally good job. :) Friendly, -- Petter Reinholdtsen Linux user #14 with the Linux Counter, URL: http://counter.li.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
Matthew Garrett writes: That should be spam - SPAM is a trademark of Hormel Foods Corporation. Only when used to sell food (in which case spam would also infringe the mark). -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
John Hasler [EMAIL PROTECTED] wrote: Matthew Garrett writes: That should be spam - SPAM is a trademark of Hormel Foods Corporation. Only when used to sell food (in which case spam would also infringe the mark). No, Hormel only claim the capitalised form. In capitalised form it's a clear reference to the food product, and as such is potentially infringing under various circumstances. See http://www.spam.com/ci/ci_in.htm -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
Matthew Garrett writes: No, Hormel only claim the capitalised form. In capitalised form it's a clear reference to the food product, and as such is potentially infringing under various circumstances. I'm quite certain that if you brought out a brand of canned pork under the label spam that US courts would find it confusingly similar to Hormel's SPAM mark. While the canonical form of a word trademark is all caps, changing the capitalization or typeface won't save you from infringement. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
Hi Matt, Am 2005-09-05 15:54:47, schrieb Matthew Garrett: Michelle Konzack [EMAIL PROTECTED] wrote: If the SPAM-Filter of Debian fails, you will shot yourself... I think, the filter trash around 99% of the SPAM. That should be spam - SPAM is a trademark of Hormel Foods Corporation. ??? Sorry, I am Extraterrest and live in France :-) Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Spam on this list
On Mon, Sep 05, 2005 at 07:42:47PM +0200, Michelle Konzack wrote: Hi Matt, Am 2005-09-05 15:54:47, schrieb Matthew Garrett: Michelle Konzack [EMAIL PROTECTED] wrote: If the SPAM-Filter of Debian fails, you will shot yourself... I think, the filter trash around 99% of the SPAM. That should be spam - SPAM is a trademark of Hormel Foods Corporation. ??? Sorry, I am Extraterrest and live in France :-) spam, as in, unsolicited bulk email, was named after a particular brand of corned beef. See http://www.spam.com/ -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
Hi, Wouter: El Lunes, 05 Septiembre 2005 19:52, Wouter Verhelst escribió: [...] spam, as in, unsolicited bulk email, was named after a particular brand of corned beef. See http://www.spam.com/ Not exactly. Spam, as unsolicited bulk email, was named after a particular Monty Python's Flying Circus show. It is Monty Python the ones that used spam after the canned meat. It might probe to be a significant difference if held in court. -- SALUD, Jesús
Re: Spam on the BTS (was: Spam on this list)
Hello Blars, Blars Blarson [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: I have also noticed tickets submitted to the bug facility that are spam. Can that facility be configured so that if the format (package name, version, etc) is not followed; the bug will not be emailed out to the lists? I've been working on the spam filtering for the BTS. We are getting over 100,000 spams/day and about 50/day get through the filters. Do you tried bogofilter or the like? Would it be acceptable to reject or drop more non-spam? Drop not, but reject. It would be the best, if you can reject spam in the SMTP dialog. Would it be acceptable to delay questionable messages for a human to review? How many message would be this? Is a spam team needed? Regards, Jörg. -- Dummheit anprangern ist ungefährlich, weil sich niemand angegriffen fühlt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS (was: Spam on this list)
On Sep 05, Joerg Sommer [EMAIL PROTECTED] wrote: Drop not, but reject. It would be the best, if you can reject spam in the SMTP dialog. Actually it's the only possible solution, a 100K msg/day backscatter source would be quickly widely blacklisted. -- ciao, Marco signature.asc Description: Digital signature
Re: Spam on the BTS (was: Spam on this list)
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Blars Blarson [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: I have also noticed tickets submitted to the bug facility that are spam. Can that facility be configured so that if the format (package name, version, etc) is not followed; the bug will not be emailed out to the lists? I've been working on the spam filtering for the BTS. We are getting over 100,000 spams/day and about 50/day get through the filters. Do you tried bogofilter No or the like? Depends how like you consider spamassassin's bayes filters, which are used. Would it be acceptable to reject or drop more non-spam? Drop not, but reject. It would be the best, if you can reject spam in the SMTP dialog. This would take cooperation from debian-admin. Would it be acceptable to delay questionable messages for a human to review? How many message would be this? Is a spam team needed? I'm already doing the reviewing, but after the messages get to the bugs. My guess is reviewing a few hundred messages/day, with a dozen or two being non-spam. The point to set could be tuned. Mainly I'd need help when I'm unavailable, but the other BTS admins would probably be willing, or this could be turned off for a few days at a time. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
On Thu, 01 Sep 2005 20:45:07 +0200, Romain Francoise [EMAIL PROTECTED] wrote: Petter Reinholdtsen [EMAIL PROTECTED] writes: You might want to consider reading the lists using NNTP to gmane.org. I read several of the lists that way, and gmane filter out the spam for me. :) And it needs money for a new dual Opteron mail server: URL: http://gmane.org/donate.php Please refrain from raising funds for other projects on Debian mailing lists. Donations solicited here should go to Debian, not somewhere else. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Spam on this list
On Sun, 2005-09-04 at 18:56 +0200, Marc Haber wrote: And it needs money for a new dual Opteron mail server: URL: http://gmane.org/donate.php Please refrain from raising funds for other projects on Debian mailing lists. Donations solicited here should go to Debian, not somewhere else. I don't see what's wrong with that. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D Signed mail welcome. Encrypted mail preferred. signature.asc Description: This is a digitally signed message part
Re: Spam on this list
Roberto C. Sanchez [EMAIL PROTECTED] writes: The problem is that being too restrictive on spam also means getting more false positives. Therefore one must find out how much more restrictive one can be without getting too restrictive. :D -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
Hi, * Pascal Hakim [EMAIL PROTECTED] [2005-09-02 10:20]: On Thu, Sep 01, 2005 at 09:03:26PM +0200, Nico Golde wrote: What about using the msgid instead of the id so it would be possible to use your MUA to mark a mail as spam via a script which can be executed and calls the spam-report.pl script just like sa-learn or something like this? So it would be possible to mark mails as spam without going to the website of the archive. What happens if someone fakes a message-id? Maybe a misunderstanding but that shouldn't be a problem. My idea is to use sa-learn or something similiar to feed it with spam mails via the spam-report.pl script. So if the msgid is not vaid no problem. Because it will be only used to identify the mail in the archive, and if the mail is found in the archive it can be piped through e.g. sa-learn. Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS (was: Spam on this list)
On Sep 01, Blars Blarson [EMAIL PROTECTED] wrote: Would it be acceptable to reject or drop more non-spam? (We could I am uncomfortable with dropping any mail, but I encourage a sensible policy to reject spam. -- ciao, Marco signature.asc Description: Digital signature
Re: Spam on the BTS (was: Spam on this list)
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Would it be acceptable to reject or drop more non-spam? (We could I am uncomfortable with dropping any mail, but I encourage a sensible policy to reject spam. Sorry if I did not make it clear before, we already are dumping 100,000 messages/day into files noone ever looks at other than in unusual situations. (If someone reports having a problem getting a message through to [EMAIL PROTECTED], I do grep through them. This happens a few times a year.) The only thing being discussed is how aggressive the spam filters are tuned, not if we do it or not. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Spam on this list
Hello: I have been noticing (and a bit irritated) at the spam I am seeing on this and some other email lists. The latest was a bit offensive for me in my work environment. I am curious; is the email list software that is used here configured to allow only registered list members to send email through the list? If it is so configured, is there any way to drop the subscriptions to those who send spam? I have also noticed tickets submitted to the bug facility that are spam. Can that facility be configured so that if the format (package name, version, etc) is not followed; the bug will not be emailed out to the lists? Thank you Mark Allyn
Re: Spam on this list
On Thu, Sep 01, 2005 at 11:11:30AM -0700, Allyn, MarkX A wrote: Hello: I have been noticing (and a bit irritated) at the spam I am seeing on this and some other email lists. The latest was a bit offensive for me in my work environment. Tell me about it. I am curious; is the email list software that is used here configured to allow only registered list members to send email through the list? No it is not. If it is so configured, is there any way to drop the subscriptions to those who send spam? See above. I have also noticed tickets submitted to the bug facility that are spam. Can that facility be configured so that if the format (package name, version, etc) is not followed; the bug will not be emailed out to the lists? Not sure about that. The problem is that being too restrictive on spam also means getting more false positives. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpT38skCu2JZ.pgp Description: PGP signature
Re: Spam on this list
[Allyn, MarkX A] I have been noticing (and a bit irritated) at the spam I am seeing on this and some other email lists. The latest was a bit offensive for me in my work environment. The debian lists are not doing a great job in blocking spam. You might want to consider reading the lists using NNTP to gmane.org. I read several of the lists that way, and gmane filter out the spam for me. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
Petter Reinholdtsen [EMAIL PROTECTED] writes: You might want to consider reading the lists using NNTP to gmane.org. I read several of the lists that way, and gmane filter out the spam for me. :) And it needs money for a new dual Opteron mail server: URL: http://gmane.org/donate.php -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
Hi, * Petter Reinholdtsen [EMAIL PROTECTED] [2005-09-01 20:42]: [Allyn, MarkX A] I have been noticing (and a bit irritated) at the spam I am seeing on this and some other email lists. The latest was a bit offensive for me in my work environment. The debian lists are not doing a great job in blocking spam. You might want to consider reading the lists using NNTP to gmane.org. I read several of the lists that way, and gmane filter out the spam for me. :) My idea was to use the spam-report.pl script which is used in the list archives to mark mails as spam. At the moment these mails will be proceeded manually by the listmasters team to hide them from the online archive. At the moment this script uses the mailing list, the date of the message and a unique id in the archive (e.g. msg00071) to identify them. What about using the msgid instead of the id so it would be possible to use your MUA to mark a mail as spam via a script which can be executed and calls the spam-report.pl script just like sa-learn or something like this? So it would be possible to mark mails as spam without going to the website of the archive. Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS (was: Spam on this list)
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: I have been noticing (and a bit irritated) at the spam I am seeing on this and some other email lists. Others have commented on this, I have little to add to this part. I have also noticed tickets submitted to the bug facility that are spam. Can that facility be configured so that if the format (package name, version, etc) is not followed; the bug will not be emailed out to the lists? I've been working on the spam filtering for the BTS. We are getting over 100,000 spams/day and about 50/day get through the filters. (Both are rough estimates, and the spam volume is continuing to rise.) There are limitations on what we can do with the resouces available. Would it be acceptable to reject or drop more non-spam? (We could reject on CBL, getting rid of about half the spam and rejecting about one non-spam per day. CBL is easy to get off of.) Would it be acceptable to delay questionable messages for a human to review? (Due to spam bursts, sometimes the BTS already takes 6 hours or more to processes the message queue.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
On Thu, Sep 01, 2005 at 11:11:30AM -0700, Allyn, MarkX A wrote: I have also noticed tickets submitted to the bug facility that are spam. Can that facility be configured so that if the format (package name, version, etc) is not followed; the bug will not be emailed out to the lists? That's exactly how it's configured for initial bug submissions, but people don't typically include a pseudo-header in follow-up mails to existing bugs so it isn't really practical to configure it that way for all bug mail. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
On Thu, Sep 01, 2005 at 09:03:26PM +0200, Nico Golde wrote: What about using the msgid instead of the id so it would be possible to use your MUA to mark a mail as spam via a script which can be executed and calls the spam-report.pl script just like sa-learn or something like this? So it would be possible to mark mails as spam without going to the website of the archive. What happens if someone fakes a message-id? Pasc -- Pascal Hakim 0403 411 672 Do Not Bend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
On Thursday 01 September 2005 06:42 pm, Colin Watson wrote: On Thu, Sep 01, 2005 at 11:11:30AM -0700, Allyn, MarkX A wrote: I have also noticed tickets submitted to the bug facility that are spam. Can that facility be configured so that if the format (package name, version, etc) is not followed; the bug will not be emailed out to the lists? That's exactly how it's configured for initial bug submissions, but people don't typically include a pseudo-header in follow-up mails to existing bugs so it isn't really practical to configure it that way for all bug mail. I was thinking this same thing, but then I realized that people *would* include a pseudo-header for follow-up mails if it were documented that this were necessary to get past the spam filters. If I'm not mistaken, reportbug already includes pseudo-headers for follow-up mails. And, we could even whitelist the bug submitter and the maintainer just to make it easier for the two most likely to comment. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: On Thu, Sep 01, 2005 at 09:03:26PM +0200, Nico Golde wrote: What about using the msgid instead of the id so it would be possible to use your MUA to mark a mail as spam via a script which can be executed and calls the spam-report.pl script just like sa-learn or something like this? So it would be possible to mark mails as spam without going to the website of the archive. What happens if someone fakes a message-id? The reports need to be verified anyway, so I fail to see the problem. Either: the message ID exists and is unique (normal case) the message ID does not exist (bogus/malformed report) the message ID exists and is not unique (chances are some if not all are spam) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: recent spam to this list
Kris Deugau wrote: OK, I think I've thought of a sort of a counter-example: [...] I'm sending from myfriendsdomain.com's server, but I don't have an account there. I do, however, have an account [EMAIL PROTECTED] on my own server- to which I want all replies/bounces/etc to go to. [...] IIRC the original question was answered to the satisfaction of the person who asked it. Listing the servers allowed to send mail from your domain, as a part of your DNS, makes perfect sense to me... all you have to do is track down the IPs of those machines. g Alternatively, you could still use [EMAIL PROTECTED] as the envelope-from when sending from *anywhere* -IF- you send through mailserver.mydomain.com using SMTP-Auth.
RE: recent spam to this list
Kris Deugau wrote: Julian Mehnle wrote: Andreas Metzler wrote: If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains Yes, you are. The envelope-from address is not a reply-to address, it's a sender address. If you are sending from mail.nusrf.at, you are not sending from logic.univie.ac.at. So you should not specify [EMAIL PROTECTED] as the envelope-from address, or you'd be forging it. OK, I think I've thought of a sort of a counter-example: [...] I'm sending from myfriendsdomain.com's server, but I don't have an account there. I do, however, have an account [EMAIL PROTECTED] on my own server- to which I want all replies/bounces/etc to go to. Why don't you use [EMAIL PROTECTED] as the envelope-from and [EMAIL PROTECTED] as the From: header field? Replies will go to [EMAIL PROTECTED], while bounces will go to [EMAIL PROTECTED]. If your friend's server is configured correctly, it won't send out-of-band bounces (bounces as stand-alone messages, instead of a bounce reply code in the SMTP dialog) to foreign (non-local) servers anyway (to mitigate joe jobs on innocent bystanders whose address was used as some spam's envelope-from). I'm not sure this actually has any direct relevance to this dicussion (which I gather is about a DNS-ish way to restrict which machines can relay mail for any particular domain, according to the wishes of that domain owner), but I think it might be a useful example. Sure, it is relevant.
Re: recent spam to this list
Julian Mehnle wrote: Kris Deugau wrote: OK, I think I've thought of a sort of a counter-example: [...] I'm sending from myfriendsdomain.com's server, but I don't have an account there. ^ I do, however, have an account [EMAIL PROTECTED] on my own server- to which I want all replies/bounces/etc to go to. Why don't you use [EMAIL PROTECTED] as the envelope-from and [EMAIL PROTECTED] as the From: header field? Replies will go to [EMAIL PROTECTED] This is OK, and proper... , while bounces will go to [EMAIL PROTECTED]. But this is bad. My friend will get a bounce for a (possibly personal) message from me to a third party, which he supposedly has no interest in seeing. About as bad as using the nonexistent [EMAIL PROTECTED] I wouldn't see the postmaster notification in either case because no email address actually associated with me personally was involved in sending my original message, except in user-generated headers that SMTP systems are, by design, supposed to ignore. If your friend's server is configured correctly, it won't send out-of-band bounces (bounces as stand-alone messages, instead of a bounce reply code in the SMTP dialog) to foreign (non-local) servers anyway (to mitigate joe jobs on innocent bystanders whose address was used as some spam's envelope-from). *shrug* If it's running any reaasonably recent Linux-based SMTP service, for the simplest case of all local users are full local accounts, for all domains accepted as local, it will generate any such rejections at SMTP time, and most others as well. It would NOT blindly relay mail from myfriendsdomain.com. For example: Case #1: I send a message to [EMAIL PROTECTED], while at this LAN party. I use an SMTP envelope address of [EMAIL PROTECTED] I mistype the destination address, so within 5-10 minutes or so, there is a postmaster notification (generated on the server hosting myfriendsdomain.com), telling me that the message couldn't be delivered because the recipient doesn't exist. OK, no problem; I can see clearly that I've mistyped something, and I can resend the message to the correct destination. No problem. Case #2: I send a message to [EMAIL PROTECTED], while at this LAN party. I use a (nonexistent!) SMTP envelope address of [EMAIL PROTECTED] I mistype the destination address, but because the SMTP return address is local, the server tries to deliver to that account. Since that doesn't exist, it bounces again to [EMAIL PROTECTED] I receive no indication that the message was *not* sucessfully (and properly) passed on to its intended destination, so three days later when talking face-to-face with [EMAIL PROTECTED], I get a little confused that he didn't get the email I sent three days earlier. Case #3: I send a message to [EMAIL PROTECTED], while at this LAN party. I use a (nonexistent!) SMTP envelope address of [EMAIL PROTECTED] I mistype the destination address, but because my first friend's address was used as the SMTP envelope sender, the bounce goes to his account. I receive no indication that the message was *not* sucessfully (and properly) passed on to its intended destination until he checks his mail- or spam folder g, so three days later when talking face-to-face with [EMAIL PROTECTED], I get a little confused that he didn't get the email I sent three days earlier. IIRC the original question was answered to the satisfaction of the person who asked it. Listing the servers allowed to send mail from your domain, as a part of your DNS, makes perfect sense to me... all you have to do is track down the IPs of those machines. g -kgd -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
Re: recent spam to this list
On Mon, Oct 13, 2003 at 05:54:41PM -0500, John Hasler wrote: No, you understood it correctly. That's exactly the point. If I can configure my domain with a list of IPs from which mail claiming to originate from it must come without having a static IP and without the cooperation of the administrators of those IPs I have exactly what I want. Sounds like you got lucky ;-) Cheers, Nick
Re: recent spam to this list
Julian Mehnle wrote: Andreas Metzler wrote: Julian Mehnle [EMAIL PROTECTED] wrote: It's about forging an e-mail sender's identity. By preventing the unauthorized use of domains as the sender domain of e-mails, most of the practiced cases of identity forgery are prevented. [...] If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains Yes, you are. The envelope-from address is not a reply-to address, it's a sender address. If you are sending from mail.nusrf.at, you are not sending from logic.univie.ac.at. So you should not specify [EMAIL PROTECTED] as the envelope-from address, or you'd be forging it. OK, I think I've thought of a sort of a counter-example: I have a private server, and an account there. I have a friend with a private server, but I do NOT have an account on that box. (Unlikely but possible; I can think of one real-world case amongst people I know running private servers.) While at a LAN party at that friend's place, I check my mail on my server, and decide I want to reply to some of the messages. Since we're both on semi-dynamic IPs (connected 24/7, but not formally assigned static IP addresses), I haven't allowed SMTP relay from the IP my friend's server is on, because I don't really know what it is today/this week/this month. But his server allows relay mail from machines on his private network, so I use his server as a relay for my mail. I'm sending from myfriendsdomain.com's server, but I don't have an account there. I do, however, have an account [EMAIL PROTECTED] on my own server- to which I want all replies/bounces/etc to go to. I'm not sure this actually has any direct relevance to this dicussion (which I gather is about a DNS-ish way to restrict which machines can relay mail for any particular domain, according to the wishes of that domain owner), but I think it might be a useful example. -kgd -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
Re: recent spam to this list
On Mon, Oct 13, 2003 at 06:51:01PM -0500, John Hasler wrote: Joel Baker writes: I'm going to gloss over the utter mistake of your first statement I am on a dialup with a dynamic IP number: I am allowed to borrow a number from my ISP at need. There is no IP number over which I have any administrative control. Thus I have no IP in that I would be unable to implement any system that required control of my IP number. This is not a problem with Dynamic DNS updates. Many places do hosting of DNS domains (only; no web or mail, etc) for absurdly cheap rates ($5/mo in some cases), and allow either DDNS or an automateable webpage to do updates with. 4) Normal end-users relaying through their home ISP, organization, or business (The Road Warrior) My ISP does not permit this. It is the only one available to me. Your ISP probably doesn't permit outbound connections from dialups to port 25 (gee, can't imagine why that might be the case...); it is amazingly rare to find an ISP that actively blocks VPN, IPSEC, *and* SSH traffic, and is still in business, however. Both for bypassing ISP filters, and for security reasons, relaying this way is fairly standard for the Road Warrior sorts (in no small part because it also protects the bare passwords that are still mostly used in POP3/IMAP servers in most situations; yes, I know about IMAP over SSL, but that doesn't do well when you need to coordinate remote salesdroids with local management, and they all use Outlook's calendar stuff to handle it). Classes 3 appears to be your situation; both this, and class 4, are removed entirely from the question of SPF/RMX/etc, because they relay through their ISP's smarthost (and thus, that smarthost is what will be checked for being allowed to send to a remote site). I cannot relay through my ISP's smarthost from outside his system. Not at all uncommon, though it might be worth trying to convince them to allow you to do *authenticated* relay from outside. Oddly enough, preventing random IPs from relaying is because... spam comes through. You smarthost your email to a server configured to handle turkey.com email, which is presumably listed in the policy, and *it* sends the email on to the remote site (which then sees it coming from that server, not you, and will accept it as coming from an approved server). That is how I thought SPF worked. This would be fine with me. However, statements made earlier in this thread seemed to me to imply that the cooperation of the administrators of domains from which mail would be originating would be required. This would be useless to me: I doubt I could get the cooperation of even my ISP, let alone some hospital or library. *Mail* has an return path that includes domain names (normally). SMTP *sessions* have a source IP. All of the protocols I saw obviously listed on the ASRG page (including at least RMX, SPF, and Vixie's proposal) use the *claimed* domain (which can be anything), and the *actual* source IP (which cannot be forged without having access to the routing hardware in between the machines, at which point you can do damned near anything you want), to decide whether it's kosher. The library's domain is irrelevant, in this case, since you're not claiming a return address in the library's domain. As a real world counterpart: if I sign up for a thousand 'free catalogs', using the address of my next door neighbor and arch nemesis Fred, he will, in fact, probably be deluged under a mountain of advertisements for lawn aeration shoes and crystal healing methods. I can do this from thousands of miles away, in fact; maybe Fred moved to Texas, and this is my long delayed revenge. Now, Fred can ask the post office to stop sending them through (and in fact, they'll probably notice it in the first place) - ISPs do similar things in a lot of cases, today, for their customers. The problem is that rather than being a rare incident of juvenile humor or mild spite, it's a business with a fairly serious amount of money involved. Now, imagine if the folks giving out catalogs had access to a no mail database in which Fred could (if he wanted to register at all), say that any attempt to request catalogs that didn't come postmarked by his local post office should be ignored. I can still mailbomb George, who hasn't signed up on the list; there may be ways to send my mail from Fred's local post office (note that the analogy stretches a bit thin on this point), but I can no longer send email from Nome, Alaska claiming to be Fred in Texas wanting catalogs. There are established ways of dealing with folks who are on the road all the time and legitimately might be anywhere in the world, but still want to get catalogs sent to their house; before I started mailbombing Fred, maybe he was fine with just sending them in with no limitations. Now he's tired of it, and it's less time and effort to deal with the hassle of updating that list, rather than A) get mailbombed,
Re: recent spam to this list
Joel Baker writes: Many places do hosting of DNS domains (only; no web or mail, etc) for absurdly cheap rates ($5/mo in some cases), and allow either DDNS or an automateable webpage to do updates with. I'm aware of these. While interesting should they start supporting SPF they are not really essential to anything I'd want to do. Your ISP probably doesn't permit outbound connections from dialups to port 25... Actually, it does. I don't use it though: when sending mail from home I'm happy to use my ISP's smarthost. Not at all uncommon, though it might be worth trying to convince them to allow you to do *authenticated* relay from outside. Authenticated relay is what I meant. I don't expect or want them to run an open relay. It is, however, pointless to try to convince them to change anything. They do not listen to customers. On the other hand, they enforce no obnoxious policies, don't have silly terms of service, and seem to be above-average in reliability. Mail* has an return path that includes domain names (normally). SMTP *sessions* have a source IP. All of the protocols I saw obviously listed on the ASRG page (including at least RMX, SPF, and Vixie's proposal) use the *claimed* domain (which can be anything), and the *actual* source IP (which cannot be forged without having access to the routing hardware in between the machines, at which point you can do damned near anything you want), to decide whether it's kosher. The library's domain is irrelevant, in this case, since you're not claiming a return address in the library's domain. I understand all that, which is why I found statements such as those in [EMAIL PROTECTED] confusing. The fact is I can add SPF records for any IP numbers I want to domains I control. Thus if I want to be able to send mail from the library or the university claiming to be from my domain I just need to add the appropriate records to my domain. The library and university have nothing to say in the matter. Look up joe job. Strictly speaking what I am suffering is not a joe job. The spammers using my domain are not actively trying to defame me: they just find it convenient to forge my domain. Widespread implementation of SPF would stop them. I've read up some more on SPF (IMHO the best of the bunch) and the rest of the ASRG proposals. SPF works exactly as I thought it did. I have no problem with any of it: I'd like to see it adopted ASAP. Some URLS: http://www.mikerubel.org/computers/rmx_records/#introduction http://spf.pobox.com/ http://spf.pobox.com/faq.html#noprevent http://spf.pobox.com/dmpvsrmx.html http://spf.pobox.com/dmpvsrmx.html http://spf.pobox.com/draft-mengwong-spf-01.txt -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: recent spam to this list
On Tue, 14 Oct 2003 10:21:23 -0500, John Hasler [EMAIL PROTECTED] said: I understand all that, which is why I found statements such as those in [EMAIL PROTECTED] confusing. The fact is I can add SPF records for any IP numbers I want to domains I control. Thus if I want to be able to send mail from the library or the university claiming to be from my domain I just need to add the appropriate records to my domain. The library and university have nothing to say in the matter. Consider this use case: I travel a lot, and stay in hotels with network connections. Unfortunately, these nigtly billed domains have very poor mail gateways; I've been burned before. I now connect directly and deliver mail from the MTA on my laptop. I do not know, a priori, what the IP address is likely to be, and getting DNS changed for datasync.com would take days, not hours, by which time I would no longer be at the IP. I do not have co-located servers; and my normal machine may not be accessible from outside to tunnel to. Just like the postcards I mail from the Hotel, the return address on my email points to a valid mbox. Would there be any way to implement tihs use case with everyone using SPF, and telling spamassassin to deep six failures? manoj -- Okay, Okay -- I admit it. You didn't change that program that worked just a little while ago; I inserted some random characters into the executable. Please forgive me. You can recover the file by typing in the code over again, since I also removed the source. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: recent spam to this list
On Tue, 14 Oct 2003, Manoj Srivastava wrote: I do not know, a priori, what the IP address is likely to be, and getting DNS changed for datasync.com would take days, not hours, by which time I would no longer be at the IP. You'd just need something akin to the ddns services... but in this case, for the SPF records. There is no technical impossibility, at all. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: recent spam to this list
Manoj Srivastava said on Tue, Oct 14, 2003 at 04:40:15PM -0500: Consider this use case: I travel a lot, and stay in hotels with network connections. Unfortunately, these nigtly billed domains have very poor mail gateways; I've been burned before. I now connect directly and deliver mail from the MTA on my laptop. I do not know, a priori, what the IP address is likely to be, and getting DNS changed for datasync.com would take days, not hours, by which time I would no longer be at the IP. I do not have co-located servers; and my normal machine may not be accessible from outside to tunnel to. Just like the postcards I mail from the Hotel, the return address on my email points to a valid mbox. Would there be any way to implement tihs use case with everyone using SPF, and telling spamassassin to deep six failures? You've got an SMTP server somewhere that accepts mail, right? (Otherwise, how do you recieve?). Configure that server to relay for people who are using SMTP AUTH, and then configure your laptop to use that as a smart host using SMTP AUTH. Then, you SPF for your smart host only; no wacky Dynamic DNS hacks required. Frankly, that kind of setup works better anyway; you get your mail off of your non-reliably connected laptop ASAP, and then let your smarthost worry about queuing. M pgpFvWTY6V9xq.pgp Description: PGP signature
Re: recent spam to this list
Manoj writes: Consider this use case: I travel a lot, and stay in hotels with network connections. Unfortunately, these nigtly billed domains have very poor mail gateways; I've been burned before. I now connect directly and deliver mail from the MTA on my laptop. I do not know, a priori, what the IP address is likely to be, and getting DNS changed for datasync.com would take days, not hours, by which time I would no longer be at the IP. I do not have co-located servers; and my normal machine may not be accessible from outside to tunnel to. Just like the postcards I mail from the Hotel, the return address on my email points to a valid mbox. Get a smtp.com account. http://www.smtp.com/ The sort of relaying you need appears to be their business (I've never done business with them myself). -- John Hasler [EMAIL PROTECTED]
Re: recent spam to this list
On Tue, Oct 14, 2003 at 04:40:15PM -0500, Manoj Srivastava wrote: On Tue, 14 Oct 2003 10:21:23 -0500, John Hasler [EMAIL PROTECTED] said: I understand all that, which is why I found statements such as those in [EMAIL PROTECTED] confusing. The fact is I can add SPF records for any IP numbers I want to domains I control. Thus if I want to be able to send mail from the library or the university claiming to be from my domain I just need to add the appropriate records to my domain. The library and university have nothing to say in the matter. Consider this use case: I travel a lot, and stay in hotels with network connections. Unfortunately, these nigtly billed domains have very poor mail gateways; I've been burned before. I now connect directly and deliver mail from the MTA on my laptop. I do not know, a priori, what the IP address is likely to be, and getting DNS changed for datasync.com would take days, not hours, by which time I would no longer be at the IP. I do not have co-located servers; and my normal machine may not be accessible from outside to tunnel to. Just like the postcards I mail from the Hotel, the return address on my email points to a valid mbox. Would there be any way to implement tihs use case with everyone using SPF, and telling spamassassin to deep six failures? manoj Given that set of constraints? No. However, as I said before, the same arguments have been used to defend open relays - and they are equally valid, or invalid, depending on whether you consider the massive abuse versus the few cases in which it is useful. Both are, in fact, fairly readily solved by the same basic method (unless port 25 is blocked outbound, which stops all chances of being able to send email out directly, as well) - relay to a smarthost that accepts SMTP AUTH. If your ISP won't do it, and your home box can't do it, perhaps it's time to consider a business investment in maintaining a mailbox with an ISP who does allow it - there are plenty to choose from. In other words: I do not accept the argument that you should be able to shift costs from you (the person wanting to do what is a fairly uncommon and non-standard configuration) to me (the person who has to go through a lot of spam to allow you to do so). In my world, my time is worth more than your money - and it's my world that decides whether *I* use SPF, domain verification, block dial-up addresses (which will also shoot you in the foot), or filter all mail from your know addresses. Or none of the above. If, and only if, much of the rest of the world makes the same value judgement, then you might have issues sending email to them - because they have said, on a policy level, that getting your email (through that configuration) is *not as important* to them as *not* getting the spam. So far, that policy seems to be a fairly popular one, if we go by the fairly directly analagous situation of who uses Open Relay lists as part of their filtering - though *most* of them that I've seen just use it as an SA rule, rather than rejecting it outright. A $19.95/mo dialup account hasn't bought you all that much of the Internet for some years now; this is simply one more door that appears likely to be closed. If you don't like that, there are perfectly workable ways to buy the ability to do what you do want, for a very reasonable price, some of which are unlikely to ever be blocked by any local ISP you may connect through. TANSTAAFL; the Commons has long since been paved over. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp3PMrpEwHAb.pgp Description: PGP signature
Re: recent spam to this list
Julian Mehnle [EMAIL PROTECTED] wrote: Andreas Metzler wrote: Julian Mehnle [EMAIL PROTECTED] wrote: It's about forging an e-mail sender's identity. By preventing the unauthorized use of domains as the sender domain of e-mails, most of the practiced cases of identity forgery are prevented. [...] If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains Yes, you are. The envelope-from address is not a reply-to address, it's a sender address. If you are sending from mail.nusrf.at, you are not sending from logic.univie.ac.at. So you should not specify [EMAIL PROTECTED] as the envelope-from address, or you'd be forging it. No, I am just specifying where I want bounces to go to. MAIL FROM:reverse-path [SP mail-parameters ] CRLF This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The reverse-path portion of the first or only argument contains the source mailbox (between and brackets), which can be used to report errors. That is practically all there is in rfc2821 about this issue. cu andreas
Re: recent spam to this list
On Mon, Oct 13, 2003 at 12:34:46AM +0200, Tollef Fog Heen wrote: * Riku Voipio I have mail-followup-set for a reason. In addition, it is normal policy on Debian lists not to Cc people unless explicitly requested. Hmm. my mutt setup appears to be b0rken then. sorry about that. need to look that. I don't want my bounces to go to the wrong place. I don't have root at all the places I send mail from, nor do I trust all those who have root there. So, I don't want my mail bounced to the wrong place. So then use a envelope-from from a domain you trust? You said that you use a specific relay to relay your mail already, so you could setup your domain (raw.no) so that only that specific IP is allowed to send mail to the world using raw.no domain? You can still put your university address in the From: field like you do right now. | Second hint: If you insist on your right to forge your email address, | anyone else can forge your address as well. Is that a right you really | need? Uhm, how would you forge your own mail address? It's like forging your own signature, something which is, by definition not possible: To quote dark: A bad analogy is like an leaky screwdriver. If you have two IP's, one at home ISP and another at work, and you send packets from your home IP using the work IP, you are forging the sender IP, even if you happen to be affiliated with both IP's. No, I can't. I don't control the DNS of my University, a few of my ISPs and so on. Nor do I control Debian's DNS. And you don't need to, unless you want to send your bounces to your university or debian servers. Why would you want to do that? One could also argue, that since the university/debian owns the domain, they can setup whatever policy they want on what IP's can send mail in the name of their domain. Lots of opposers seem to assume that domain owners will immediately apply an policy that will force senders to use their mail relays for outgoing mail, without consulting their users first. | The antipathy against the a POSSIBILITY of a domain owner to restrict | sending mail in name of his own domain to few IP's is what is silly, | not the proposal... It's the wrong solution. And what is the right solution? One that even the blondes using hotmail can use? Just accept it as fact of life that viruses and spam use every now and then your domains? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
RE: recent spam to this list
Andreas Metzler wrote: Julian Mehnle [EMAIL PROTECTED] wrote: Andreas Metzler wrote: If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains Yes, you are. The envelope-from address is not a reply-to address, it's a sender address. If you are sending from mail.nusrf.at, you are not sending from logic.univie.ac.at. So you should not specify [EMAIL PROTECTED] as the envelope-from address, or you'd be forging it. No, I am just specifying where I want bounces to go to. MAIL FROM:reverse-path [SP mail-parameters ] CRLF This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The reverse-path portion of the first or only argument contains the source mailbox (between and brackets), which can be used to report errors. There you have it. It's the source mailbox, and while it can be used to report errors, it can *not only* be used to report errors. I'm relieved that the RFC doesn't contradict my common sense understanding of a sender address.
Re: recent spam to this list
On Mon, Oct 13, 2003 at 02:47:44PM +0200, Julian Mehnle wrote: Andreas Metzler wrote: Julian Mehnle [EMAIL PROTECTED] wrote: Andreas Metzler wrote: If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains Yes, you are. The envelope-from address is not a reply-to address, it's a sender address. If you are sending from mail.nusrf.at, you are not sending from logic.univie.ac.at. So you should not specify [EMAIL PROTECTED] as the envelope-from address, or you'd be forging it. No, I am just specifying where I want bounces to go to. MAIL FROM:reverse-path [SP mail-parameters ] CRLF This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The reverse-path portion of the first or only argument contains the source mailbox (between and brackets), which can be used to report errors. There you have it. It's the source mailbox, and while it can be used to report errors, it can *not only* be used to report errors. I'm relieved that the RFC doesn't contradict my common sense understanding of a sender address. I does not confirm it. There is no such thing as the domain part of the reverse-path should/has to/must be identical to the domain name of the machine the mail was written on originally, it just states that reverse-path can be used to report errors to. cu andreas
RE: recent spam to this list
Andreas Metzler wrote: On Mon, Oct 13, 2003 at 02:47:44PM +0200, Julian Mehnle wrote: There you have it. It's the source mailbox, and while it can be used to report errors, it can *not only* be used to report errors. I'm relieved that the RFC doesn't contradict my common sense understanding of a sender address. I does not confirm it. Confirm what? My common sense understanding of a sender address? Hopefully RFCs wouldn't have to define *everything* they relate to, since common sense already defines a lot of it. Don't you agree on my understanding of a sender address (or source mailbox) being the address (or source mailbox) the sender sends from? If so, please state it explicitly, so I have something I can argue against. :-) There is no such thing as the domain part of the reverse-path should/has to/must be identical to the domain name of the machine the mail was written on originally, it just states that reverse-path can be used to report errors to. RFC 2821 may not state that. So the cited proposals (like SPF, etc.) were created as proposed amendments to RFC 2821, and *they* do demand that -- for domains that have been configured that way, not for other domains. So where do you see a problem?
Re: recent spam to this list
Julian Mehnle writes: Don't you agree on my understanding of a sender address (or source mailbox) being the address (or source mailbox) the sender sends from? If so, please state it explicitly, so I have something I can argue against. :-) Mail is not sent from any particular address at all; it is sent by a person or program. It is delivered to one or more addresses. The From: address and SMTP and envelope sender addresses are for human understanding and status reporting. Forgery generally means to create written authorization that shows false provenance. A user who indicates status messages should go to his own address is not forging that address, even if it is not an obvious address given the user's hostname. It probably is useful to perform checks on those addresses, to verify that the administrator of the domain allows the sender to claim an identity under the domain. If such an authorization check fails, forgery is just one possible explanation. Michael
RE: recent spam to this list
Michael Poole wrote: Julian Mehnle writes: Don't you agree on my understanding of a sender address (or source mailbox) being the address (or source mailbox) the sender sends from? If so, please state it explicitly, so I have something I can argue against. :-) Mail is not sent from any particular address at all; it is sent by a person or program. It is delivered to one or more addresses. The From: address and SMTP and envelope sender addresses are for human understanding and status reporting. It does very well make sense to specify a sender address for an e-mail, and that's exactly what the SMTP MAIL FROM command AKA envelope-from (and the Sender: header) is meant to be. Even RFCs (2)821 and (2)822 articulate it that way. Nowhere do these RFCs state that the envelope-from can or should be used for status reporting *only*, do they? Forgery generally means to create written authorization that shows false provenance. No. You can also forge paintings as well as originator address specifications and other information. Call it counterfeiting, but essentially it's the same thing. A user who indicates status messages should go to his own address is not forging that address, even if it is not an obvious address given the user's hostname. Agreed, but a user indicating a MAIL FROM: [EMAIL PROTECTED] while sending from a host in the bar.org domain is forging the MAIL FROM address. It probably is useful to perform checks on those addresses, to verify that the administrator of the domain allows the sender to claim an identity under the domain. If such an authorization check fails, forgery is just one possible explanation. Generally true, but in part it depends on how you define forgery.
Re: recent spam to this list
Julian Mehnle writes: It does very well make sense to specify a sender address for an e-mail, and that's exactly what the SMTP MAIL FROM command AKA envelope-from (and the Sender: header) is meant to be. Even RFCs (2)821 and (2)822 articulate it that way. Nowhere do these RFCs state that the envelope-from can or should be used for status reporting *only*, do they? If I go to Eau Claire and drop a letter in a letter box am I required to put the address of the box on the letter? Am I forging if I put my Elmwood address on it instead? How about if I go into a library in Eau Claire and send an email? Why should I not put my Elmwood address on it? Of what possible use to anyone would the address of the machine I sent it from be? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: recent spam to this list
Julian Mehnle writes: Michael Poole wrote: Mail is not sent from any particular address at all; it is sent by a person or program. It is delivered to one or more addresses. The From: address and SMTP and envelope sender addresses are for human understanding and status reporting. It does very well make sense to specify a sender address for an e-mail, and that's exactly what the SMTP MAIL FROM command AKA envelope-from (and the Sender: header) is meant to be. Even RFCs (2)821 and (2)822 articulate it that way. Nowhere do these RFCs state that the envelope-from can or should be used for status reporting *only*, do they? In that context, I think the reasonable interpretation for sender address is one that will reach the sender. There need not be a unique valid sender address for any person, any role, any host, or any combination of those three -- unless the relevant administrators dictate it. I contend that a from or sender address is forged *only* if that address reaches neither the actual originator nor anyone who delegated that identity to the actual originator. A valid sender may be rejected if they are acting contrary to how their administrator desires them to act -- specifically, if they send email with that address through unauthorized servers. That is a failed authorization check, not a failed forgery check, since you do not know whether the sender is or is not the proper person. [snip] Agreed, but a user indicating a MAIL FROM: [EMAIL PROTECTED] while sending from a host in the bar.org domain is forging the MAIL FROM address. That is what I disagree with. You have given no clear argument for that claim -- or even a definition of what 'a host in the bar.org domain' means. I assume you mean that the IP resolves using DNS PTR records to a host matching either *.bar.org or bar.org, and that the hostname has a DNS A record that points back to the IP. Forged emails generally have that domain mismatch, but some valid emails share it. For example, my host is in the troilus.org domain, and about half of my mail uses the address I send this email from. Most of the rest uses another address, and the remainder is from a third. The latter two refer unambiguously to me and eventually end up in the same mailbox as the rest of my mail, so I do not see why using them in MAIL FROM: should be considered forgery. On the other hand, it is possible for a user to forge an envelope sender to make himself look like another user in the same domain. Your naive detection scheme for forgery fails to detect this. It probably is useful to perform checks on those addresses, to verify that the administrator of the domain allows the sender to claim an identity under the domain. If such an authorization check fails, forgery is just one possible explanation. Generally true, but in part it depends on how you define forgery. Without getting into a debate over semantics, it seems that you define forgery in a counter-intuitive way by ignoring ways that real people use protocols: specifically, arguing that SMTP forgery is defined by hostnames rather than user identity. Michael
RE: recent spam to this list
John Hasler wrote: Julian Mehnle writes: It does very well make sense to specify a sender address for an e-mail, and that's exactly what the SMTP MAIL FROM command AKA envelope-from (and the Sender: header) is meant to be. Even RFCs (2)821 and (2)822 articulate it that way. Nowhere do these RFCs state that the envelope-from can or should be used for status reporting *only*, do they? If I go to Eau Claire and drop a letter in a letter box am I required to put the address of the box on the letter? No, but this again is one of these broken e-mail vs. real world analogies. You can't receive mail through such a letter box, but a sender address is inherently meant to be a valid address through which you can be contacted (among other criteria). Sender address forgery is not a serious problem with snail mail, but it is with e-mail. And with e-mail, it is possible to do things that are hardly possible with snail mail, e.g. checking the authenticity of the sender address. An e-mail's sender address domain should (in this regard) better be compared to the stamp of the post office where the letter was accepted. How about if I go into a library in Eau Claire and send an email? Why should I not put my Elmwood address on it? You may put your Elmwood address into the From: or Reply-To: fields, but should not specify it as the envelope-from. Of what possible use to anyone would the address of the machine I sent it from be? If the sender address (envelope-from) of an e-mail was unforgeable (for a given domain), the sender would be guaranteed to have an account at this domain (and be it only to *send* mail), and any abuse could be reliably traced back to the sender's account (not just to the sending host). That's what address forgers fear.
Re: recent spam to this list
Julian Mehnle writes: No, but this again is one of these broken e-mail vs. real world analogies. You can't receive mail through such a letter box, but a sender address is inherently meant to be a valid address through which you can be contacted (among other criteria). I can no more be contacted via the machine in that library than I can via the letterbox. I go in there, spend five minutes sending an email and leave, expecting any replies or bounces to go to my real address. If my message is bounced to that box or a reply sent there it will vanish without a trace. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
RE: recent spam to this list
John Hasler wrote: Julian Mehnle writes: No, but this again is one of these broken e-mail vs. real world analogies. You can't receive mail through such a letter box, but a sender address is inherently meant to be a valid address through which you can be contacted (among other criteria). I can no more be contacted via the machine in that library than I can via the letterbox. I go in there, spend five minutes sending an email and leave, expecting any replies or bounces to go to my real address. If my message is bounced to that box or a reply sent there it will vanish without a trace. Then it's up to the library to decide whether to offer this feature (envelope-from forgery, or call it envelope-from pretendery) or protect its domain from unauthorized use in envelope-froms. Of course the latter option implies restrictions for users like you, but the library is not at all required to implement these restrictions for its domain. I still don't understant why so many people object against the cited proposals... The implementation on the sending side (i.e. the DNS configuration) is entirely optional.
Re: recent spam to this list
On Mon, Oct 13, 2003 at 08:06:33PM +0200, Julian Mehnle wrote: John Hasler wrote: Julian Mehnle writes: No, but this again is one of these broken e-mail vs. real world analogies. You can't receive mail through such a letter box, but a sender address is inherently meant to be a valid address through which you can be contacted (among other criteria). I can no more be contacted via the machine in that library than I can via the letterbox. I go in there, spend five minutes sending an email and leave, expecting any replies or bounces to go to my real address. If my message is bounced to that box or a reply sent there it will vanish without a trace. Then it's up to the library to decide whether to offer this feature (envelope-from forgery, or call it envelope-from pretendery) or protect its domain from unauthorized use in envelope-froms. Of course the latter option implies restrictions for users like you, but the library is not at all required to implement these restrictions for its domain. I still don't understant why so many people object against the cited proposals... The implementation on the sending side (i.e. the DNS configuration) is entirely optional. Probably because systems which expect it and don't see it will do something such as give the message a positive SpamAssassin score. Of course, if you're going to do something that happens to look like what a lot of spammers do, you should probably expect that, just like it's not wise (anymore) to put a lot of !s in your subject, or to use a known open relay, even if you have absolute permission to use it for legitimate email... Really, this just isn't that difficult a concept, even if it doesn't map directly to real world mail. Your identity, as given in various places, is multi-part; both a user part, *and* a domain part. The owners of the domain part are free to set any policy they wish (including we don't care), regarding the behavior of people who wish to claim association with them (perhaps the cloest analogy would be fufilling any requirements for using, say, the official Debian name). In fact, the debian.org domain is a very good example. The policies say that you shouldn't use it for a variety of purposes; they could (though I don't think they *should*) also say due to problems with forged email claiming to be from Debian, all Debian-official email must relay through the following servers: list. For Debian, which has little interest in running relay servers, highly technical users, and a relatively small problem with spam claiming to be from the domain, in general, it isn't worth the annoyance to the users (IMO). For a University, who are very liability-shy, who mostly have users using a single system, and who already run significant outbound relays for most of their users... it may be much more of a win. It's just (another) tool for enforcing policy, like everything in layers 1-7; it can help make certain policies practical, but it cannot decide when or where to make those policies the case. If you don't like the policy someone implements with it, you can complain to them - maybe they'll listen, maybe not. For a lot of us who've been dealing with the load on mailservers for years, I'm sorry, but your individual desire to be able to send mail from anywhere on the planet, claiming to be anyone on the planet, does not (in my policy decisions) outweight my desire to get fewer spams every day. If adding .1 to your SA score for lacking a repudiation protocol, and 3 (or 5, or whatever) for claiming to be from a domain that denies that it origionates mail to the rest of the world from your IP, is enough to help me sort through my mailbox - so be it. If it isn't, I won't use it, and you have nothing to worry about. However, arguments about 'it will make my life harder' apply just as well to things like open relays, and they are the heart of a large number of anti-spam lists, since there is a very high correlation between having it open, and origionating large amounts of spam. Nearly 100%, in fact. If lacking a domain-authorized relay point comes to eventually have the same statistics, you'd better bet that you'll have the same sorts of penalties in spamfilters. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpMt0YodGu7F.pgp Description: PGP signature
Re: recent spam to this list
Joel Baker writes: I'm sorry, but your individual desire to be able to send mail from anywhere on the planet, claiming to be anyone on the planet... What makes you think I want to claim to be anyone on the planet? I have a valid domain and I want replies and bounces to go to it. If adding .1 to your SA score for lacking a repudiation protocol, and 3 (or 5, or whatever) for claiming to be from a domain that denies that it origionates mail to the rest of the world from your IP... I have no IP. Outgoing mail from home goes via my ISP's smarthost. Incoming mail goes to his POP server. If lacking a domain-authorized relay point comes to eventually have the same statistics, you'd better bet that you'll have the same sorts of penalties in spamfilters. What do you mean by a domain-authorized relay point? It was my understanding that the idea behind SPF was that I would list in the DNS for my domain the IPs that were authorized to send mail claiming to be from my domain. That would be fine with me, but I evidently misunderstood. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
RE: recent spam to this list
John Hasler wrote: Joel Baker writes: If adding .1 to your SA score for lacking a repudiation protocol, and 3 (or 5, or whatever) for claiming to be from a domain that denies that it origionates mail to the rest of the world from your IP... I have no IP. Outgoing mail from home goes via my ISP's smarthost. Incoming mail goes to his POP server. Consider your ISP's smarthost's IP address your IP. It makes no difference. If lacking a domain-authorized relay point comes to eventually have the same statistics, you'd better bet that you'll have the same sorts of penalties in spamfilters. What do you mean by a domain-authorized relay point? It was my understanding that the idea behind SPF was that I would list in the DNS for my domain the IPs that were authorized to send mail claiming to be from my domain. That would be fine with me, but I evidently misunderstood. No, you understood it correctly. That's exactly the point.
Re: recent spam to this list
On Mon, Oct 13, 2003 at 04:26:35PM -0500, John Hasler wrote: Joel Baker writes: I'm sorry, but your individual desire to be able to send mail from anywhere on the planet, claiming to be anyone on the planet... What makes you think I want to claim to be anyone on the planet? I have a valid domain and I want replies and bounces to go to it. If you're doing what these proposals are meant to block - that is, sending email from a random IP on the internet without cryptographic authentication data at the protocol level - then you can claim to be [EMAIL PROTECTED] just as easily as you can claim to be your legitimate email. Opening up the ability to do it for legitimate uses opens up the ability to use it for illegitimate ones, as well - and this has a proven (and high) cost. If adding .1 to your SA score for lacking a repudiation protocol, and 3 (or 5, or whatever) for claiming to be from a domain that denies that it origionates mail to the rest of the world from your IP... I have no IP. Outgoing mail from home goes via my ISP's smarthost. Incoming mail goes to his POP server. I'm going to gloss over the utter mistake of your first statement (unless you happen to connect to your mail server over SNA, IPX, or some stranger option), and point out that the second statement automatically removes you - entirely - from the issue at hand. If you're sending your email to your ISP's smarthost, then *it*, not *you*, are what talks to the remote mailserver - and, as such, it's IP (not yours) is what will be checked. So, unless your ISP pulls a boneheaded misconfiguration, either there will be no published policy (that is, anyone can send), or the policy will list that smarthost as authorized. If lacking a domain-authorized relay point comes to eventually have the same statistics, you'd better bet that you'll have the same sorts of penalties in spamfilters. What do you mean by a domain-authorized relay point? It was my understanding that the idea behind SPF was that I would list in the DNS for my domain the IPs that were authorized to send mail claiming to be from my domain. That would be fine with me, but I evidently misunderstood. Understand that there are five normal situations that cover pretty much all non-pathological sources of email on the Internet today: 1) Private mailserver run by a business, co-op, or highly technical single user (enterprise servers). 2) ISP mailservers (just what they sound like) 3) Normal end-users relaying through their connection ISP (Joe Dialup) 4) Normal end-users relaying through their home ISP, organization, or business (The Road Warrior) 5) Normal end-users delivering directly. Class #1 is generally a business account of some sort; it costs more than $19.95/mo, and is expected to be able to send and receive email directly, as a rule. Also, as a rule, they can control their own DNS (either by running a server, or by having update control from whomever they pay to do hosting for their domain). Class #2 is fairly obvious, though the line between normal business and ISP can blur somewhat if your business has an IT department serving tens of thousands of users. They almost certain run their own DNS servers, and can afford someone compentant to run them. These two classes have a strong business case for needing to send their own email rather than let an ISP handle it for them; they frequently have access through more than one ISP, and can easily (and legitimately) generate hundreds of thousands of emails an hour, which would put an excessive load on the mailservers of an ISP for one customer, if so. Classes 3 appears to be your situation; both this, and class 4, are removed entirely from the question of SPF/RMX/etc, because they relay through their ISP's smarthost (and thus, that smarthost is what will be checked for being allowed to send to a remote site). Class 5 are the people who regularly used to use open relays (instead of smarthosting), and who now want to be able to send emails directly (without having to smarthost). They are the only ones such proposals hamper in any significant way. Your understand above is correct - note that you would list your *ISP's* mailservers (probably the same smarthost you send to as their customer, but possibly others; they would be able to tell you which ones) for your domain, since that's where mail is expected to come from. In fact, if you have something spiffy like Dynamic DNS updates arranged, you can even send directly from your current IP, by updating the DNS to say This dynamic IP I got is authorized to send email for my domain. What you *won't* be able to do, if the proposals are widely adopted, is to send email claiming to be from [EMAIL PROTECTED], unless one of the following things is true: 1) The DNS for turkey.com has no published policy (entries in the DNS for whatever protocol is adopted, saying only these mailservers can send). Lacking a policy statement, the sane default is traditional,
Re: recent spam to this list
Julian Mehnle writes: Consider your ISP's smarthost's IP address your IP. It makes no difference. It would if the proposed system was unusable by those of us without static IPs, which was the impression I was getting. Evidently that impression was incorrect: good. No, you understood it correctly. That's exactly the point. If I can configure my domain with a list of IPs from which mail claiming to originate from it must come without having a static IP and without the cooperation of the administrators of those IPs I have exactly what I want. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: recent spam to this list
Joel Baker writes: I'm going to gloss over the utter mistake of your first statement I am on a dialup with a dynamic IP number: I am allowed to borrow a number from my ISP at need. There is no IP number over which I have any administrative control. Thus I have no IP in that I would be unable to implement any system that required control of my IP number. 4) Normal end-users relaying through their home ISP, organization, or business (The Road Warrior) My ISP does not permit this. It is the only one available to me. Classes 3 appears to be your situation; both this, and class 4, are removed entirely from the question of SPF/RMX/etc, because they relay through their ISP's smarthost (and thus, that smarthost is what will be checked for being allowed to send to a remote site). I cannot relay through my ISP's smarthost from outside his system. You smarthost your email to a server configured to handle turkey.com email, which is presumably listed in the policy, and *it* sends the email on to the remote site (which then sees it coming from that server, not you, and will accept it as coming from an approved server). That is how I thought SPF worked. This would be fine with me. However, statements made earlier in this thread seemed to me to imply that the cooperation of the administrators of domains from which mail would be originating would be required. This would be useless to me: I doubt I could get the cooperation of even my ISP, let alone some hospital or library. If it's a choice between being nice to the people in class 5, and having a thousand fewer emails a week to sift through in *my* mailbox, they can take a flying leap. None of them are important enough (right now) that I want to get their emails *more* than I want to *not* get that many spams/broken autoresponders/viruses/etc. I get several hundred per day, many indicating that some SOB is sending libelous and obscene spams in my name. If SPF works as it seems I want it ASAP. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: recent spam to this list
* Gerfried Fuchs (Discussion moved from -private, all text and references which refer to stuff not ok to quote outside -private removed.) | * Tollef Fog Heen [EMAIL PROTECTED] [2003-10-09 22:03]: | | I think it's a silly proposal, since it will hinder people like me who | are sending all their mail from a laptop to send their mail properly. | | The concept of SMTP AUTH is completely new to you, is it? Sorry, these | kind of objections are just as silly as you call the proposal silly. Uhm, no, why should it be? Having gnus set up to use SMTP auth and using a different server based on what the From address is would suck and be non-trivial. | but it'll suck for mobile users in general. | | Mobile users are strongly encouraged to use SMTP AUTH. How would you set up so that my laptop (or yours or whoever's) can send mail from about ten different domains if the server you are sending to is using SPF and the domain you are sending from have it implemented in DNS? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
RE: recent spam to this list
Tollef Fog Heen wrote: * Gerfried Fuchs The concept of SMTP AUTH is completely new to you, is it? Sorry, these kind of objections are just as silly as you call the proposal silly. Uhm, no, why should it be? Having gnus set up to use SMTP auth and using a different server based on what the From address is would suck and be non-trivial. Oh, come on! Even Outlook supports that. How would you set up so that my laptop (or yours or whoever's) can send mail from about ten different domains if the server you are sending to is using SPF and the domain you are sending from have it implemented in DNS? Convince the owner of these domains that you are (that is, your outgoing mail server is) allowed to send mail from these domains?
Re: recent spam to this list
In article [EMAIL PROTECTED], Andreas Metzler [EMAIL PROTECTED] wrote: SMTP AUTH is no magic solution, you'd have to start routing mail by sender instead of recipient. Take myself, sharing a computer at home with somebody else who uses a completely different domain for her e-mail. Currently I simply take all mail and throw it to my current[1] internet access provider's smarthost. I would have to change the mail routing to send mail from me to smarthost A and mail from the other person to smarthost B. Even myself alone uses different domains for my mail, e.g. very rarely @debian.org. You know, there is a difference between Envelope-From (SMTP MAIL FROM:) and whatever you put in the From: header. They don't have to be the same. Unfortunately, almost noone seems to realize this (in particular, developers of mail software for the windows platform ...) Mike. -- Never trust a statistic you didn't fake yourself.
Re: recent spam to this list
Julian Mehnle [EMAIL PROTECTED] wrote: Tollef Fog Heen wrote: [...] How would you set up so that my laptop (or yours or whoever's) can send mail from about ten different domains if the server you are sending to is using SPF and the domain you are sending from have it implemented in DNS? Convince the owner of these domains that you are (that is, your outgoing mail server is) allowed to send mail from these domains? Think these domains = debian.org and outgoing mail server = every smarthost that is provided by an internet access provider around the globe. You either end up with publishing records for @debian.org that allow any server to send with MAIL FROM:[EMAIL PROTECTED] (no gain, that is exactly what we have currently) or force people to route their mail by sender, i.e. manually. cu andreas
Re: recent spam to this list
Miquel van Smoorenburg [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Andreas Metzler [EMAIL PROTECTED] wrote: SMTP AUTH is no magic solution, you'd have to start routing mail by sender instead of recipient. Take myself, sharing a computer at home with somebody else who uses a completely different domain for her e-mail. Currently I simply take all mail and throw it to my current[1] internet access provider's smarthost. I would have to change the mail routing to send mail from me to smarthost A and mail from the other person to smarthost B. Even myself alone uses different domains for my mail, e.g. very rarely @debian.org. You know, there is a difference between Envelope-From (SMTP MAIL FROM:) and whatever you put in the From: header. They don't have to be the same. [...] I do know that, but e.g. (closed) mailing-lists check the envelope from. And it does not help in the first szenario at all (unless you think it to be ok that user a receives the bounces for user b). cu andreas
Re: recent spam to this list
In article [EMAIL PROTECTED], Andreas Metzler [EMAIL PROTECTED] wrote: Miquel van Smoorenburg [EMAIL PROTECTED] wrote: You know, there is a difference between Envelope-From (SMTP MAIL FROM:) and whatever you put in the From: header. They don't have to be the same. [...] I do know that, but e.g. (closed) mailing-lists check the envelope from. Which is arguably broken. The list should allow you to set up multiple address that you can post from (any many do). And it does not help in the first szenario at all (unless you think it to be ok that user a receives the bounces for user b). If you read RFC822 and see the distinction between Sender: and From: that isn't really as strange as it would seem. Sure, it isn't as flexible as the current solution (impersonate whoever you want) but that is going to be true of *any* better solution, alas. And I don't think you can get all users to sign their e-mail with PGP or use SMTP AUTH exclusively overnight. You need something that will work in most cases, without end-user changes, on the current Internet. This is something that if it breaks, it will most likely be for the users who know how to fix it. I don't like SPF much either. I've just come to the conclusion that it's probably better than nothing. Mike. -- Never trust a statistic you didn't fake yourself.
Re: recent spam to this list
Miquel van Smoorenburg [EMAIL PROTECTED] wrote: [...] And it does not help in the first szenario at all (unless you think it to be ok that user a receives the bounces for user b). Just for a reminder: Two people using different domains with a changing smarthost on one computer. If you read RFC822 and see the distinction between Sender: and From: that isn't really as strange as it would seem. It does not seem strange at all to me that envelope from gets the bounce. Sure, it isn't as flexible as the current solution (impersonate whoever you want) but that is going to be true of *any* better solution, alas. Probably. And I don't think you can get all users to sign their e-mail with PGP or use SMTP AUTH exclusively overnight. You need something that will work in most cases, without end-user changes, on the current Internet. Agreed, the alternative suggestions who think that forcing anybody to use authenticated SMTP together with certificate-checked SSL between SMT-server's totally ignore the complexity of setting up and enforcing a global web of trust. You need something that will work in most cases, without end-user changes, on the current Internet. I am just not very confident that SPF and similar stuff will work as well as proposed. I think after a short time spammers will just get the needed bit smarter, and all we get for going through the pain of implementing SPF is making abuse work easier. This is something that if it breaks, it will most likely be for the users who know how to fix it. [...] I do not know how to fix the szenario listed above. I can only think of these possibilties, neither of which is a good enough to be considered a fix. * Rewrite envelope from two one user and ignore the privacy concerns - me getting somebody else's bounce message. * Throw away flexibility. Select an internet acces provider who offers e-mail addrsses, everybody on the computer has to switch to a mailbox by this provider. * Buy a domain and root server (i.e. computer with a fixed IP) and host the domain and my own smarthost there. Every local user has to use an e-mail on my domain. * Route by sender, it is manual work, and would not work for me, as the smarthosts connected to e-mail addresses don't do SMTP AUTH. cu andreas
Re: recent spam to this list
On Thu, Oct 09, 2003 at 10:03:45PM +0200, Tollef Fog Heen wrote: * Joel Baker | Last I checked, this was (unfortunately) not yet an RFC, but only a draft | proposal. It happens to be one I really like the idea of, but I am aware | of more or less 'nobody' implementing it, nor any significant support for | it in the major SMTP servers (though I'd love to have someone point out | anything I'm missing, on that front...) Actually, It's worse. There is three[1] slightly diffrent proposals at the moment. There is work going on merging these proposals, so it definetly too early to adopt these proposals. The implementation in majos SMTP servers isn't that large problem, most mailers are modular enough these days to handle the problem with an external module. I think it's a silly proposal, since it will hinder people like me who are sending all their mail from a laptop to send their mail properly. And I think you didn't read the proposals and the discussion related to them at all. First hint: envelope from vs ^From: Second hint: If you insist on your right to forge your email address, anyone else can forge your address as well. Is that a right you really need? Third hint: You can still choose to allow any IP send emails in your domains name. Just do not add the records in dns, and everything will stay as it is currently. The antipathy against the a POSSIBILITY of a domain owner to restrict sending mail in name of his own domain to few IP's is what is silly, not the proposal... Of course, techies like we will find a way around it by tunnelling mail through a ssh tunnel or the equivalent, but it'll suck for mobile users in general. and most non-technical users will probably have one address and one SMPT AUTH based mail server to use. [1] http://spf.pobox.com/ http://www.danisch.de/work/security/antispam.html http://www.pan-am.ca/dmp/dmp-faq.html -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: recent spam to this list
* Riku Voipio [EMAIL PROTECTED] [031012 20:25]: Second hint: If you insist on your right to forge your email address, anyone else can forge your address as well. Is that a right you really need? It's about to *use* an e-mail address, not about forging one... Third hint: You can still choose to allow any IP send emails in your domains name. Just do not add the records in dns, and everything will stay as it is currently. The antipathy against the a POSSIBILITY of a domain owner to restrict sending mail in name of his own domain to few IP's is what is silly, not the proposal... Well, this proposal sounds like People who do not want to get hit by falling statlites should wear a fish on their head. I'm against this proposal, even though I would not even wear a fish on my head, if it became a law. MfG, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
RE: recent spam to this list
(Bernhard, please excuse the accidental CC!) Bernhard R. Link wrote: * Riku Voipio [EMAIL PROTECTED] [031012 20:25]: Second hint: If you insist on your right to forge your email address, anyone else can forge your address as well. Is that a right you really need? It's about to *use* an e-mail address, not about forging one... It's about forging an e-mail sender's identity. By preventing the unauthorized use of domains as the sender domain of e-mails, most of the practiced cases of identity forgery are prevented. [...] I'm against this proposal [...] Does this have a reason? And if yes: which?
RE: recent spam to this list
(Andreas, please excuse the accidental CC!) Andreas Metzler wrote: Julian Mehnle [EMAIL PROTECTED] wrote: Convince the owner of these domains that you are (that is, your outgoing mail server is) allowed to send mail from these domains. Think these domains = debian.org and outgoing mail server = every smarthost that is provided by an internet access provider around the globe. You either end up with publishing records for @debian.org that allow any server to send with MAIL FROM:[EMAIL PROTECTED] (no gain, that is exactly what we have currently) or force people to route their mail by sender, i.e. manually. By none of the mentioned proposals is every domain required to restrict the set of allowed sending hosts. Every domain owner who doesn't want that restriction for his domain may very well ignore these proposals.
Re: recent spam to this list
Julian Mehnle [EMAIL PROTECTED] wrote: (Bernhard, please excuse the accidental CC!) Bernhard R. Link wrote: * Riku Voipio [EMAIL PROTECTED] [031012 20:25]: Second hint: If you insist on your right to forge your email address, anyone else can forge your address as well. Is that a right you really need? It's about to *use* an e-mail address, not about forging one... It's about forging an e-mail sender's identity. By preventing the unauthorized use of domains as the sender domain of e-mails, most of the practiced cases of identity forgery are prevented. [...] If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains cu andreas
Re: recent spam to this list
* Riku Voipio I have mail-followup-set for a reason. In addition, it is normal policy on Debian lists not to Cc people unless explicitly requested. | I think it's a silly proposal, since it will hinder people like me who | are sending all their mail from a laptop to send their mail properly. | | And I think you didn't read the proposals and the discussion related to them | at all. You are wrong. | First hint: envelope from vs ^From: I don't want my bounces to go to the wrong place. I don't have root at all the places I send mail from, nor do I trust all those who have root there. So, I don't want my mail bounced to the wrong place. | Second hint: If you insist on your right to forge your email address, | anyone else can forge your address as well. Is that a right you really | need? Uhm, how would you forge your own mail address? It's like forging your own signature, something which is, by definition not possible: 4. To make falsely; to produce, as that which is untrue or not genuine; to fabricate; to counterfeit, as, a signature, or a signed document. [1913 Webster] | Third hint: You can still choose to allow any IP send emails in your | domains name. Just do not add the records in dns, and everything will | stay as it is currently. No, I can't. I don't control the DNS of my University, a few of my ISPs and so on. Nor do I control Debian's DNS. | The antipathy against the a POSSIBILITY of a domain owner to restrict | sending mail in name of his own domain to few IP's is what is silly, | not the proposal... It's the wrong solution. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
RE: recent spam to this list
Andreas Metzler wrote: Julian Mehnle [EMAIL PROTECTED] wrote: It's about forging an e-mail sender's identity. By preventing the unauthorized use of domains as the sender domain of e-mails, most of the practiced cases of identity forgery are prevented. [...] If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains Yes, you are. The envelope-from address is not a reply-to address, it's a sender address. If you are sending from mail.nusrf.at, you are not sending from logic.univie.ac.at. So you should not specify [EMAIL PROTECTED] as the envelope-from address, or you'd be forging it.
RE: recent spam to this list
Tollef Fog Heen wrote: * Riku Voipio Second hint: If you insist on your right to forge your email address, anyone else can forge your address as well. Is that a right you really need? Uhm, how would you forge your own mail address? It's like forging your own signature, something which is, by definition not possible: A sender address, which the envelope-from is, is neither a signature nor an identity token (although it's often abused as such). It's an address. As I already responded[1] to Andreas Metzler a few minutes ago, it's very well possible to forge a sender address. Third hint: You can still choose to allow any IP send emails in your domains name. Just do not add the records in dns, and everything will stay as it is currently. No, I can't. I don't control the DNS of my University, a few of my ISPs and so on. Nor do I control Debian's DNS. Although Debian might not want it, maybe that's exactly what the University wants. Maybe they want you to use their mail server to send mails when using their domain in the sender address, so they have control over how the service e-mail is used under their domain. And everyone please stop making broken e-mail vs. real world analogies. [1] [EMAIL PROTECTED]
Re: recent spam to this list
On Sun, Oct 12, 2003 at 11:41:45PM +0200, Andreas Metzler wrote: Julian Mehnle [EMAIL PROTECTED] wrote: Bernhard R. Link wrote: * Riku Voipio [EMAIL PROTECTED] [031012 20:25]: Second hint: If you insist on your right to forge your email address, anyone else can forge your address as well. Is that a right you really need? It's about to *use* an e-mail address, not about forging one... It's about forging an e-mail sender's identity. By preventing the unauthorized use of domains as the sender domain of e-mails, most of the practiced cases of identity forgery are prevented. [...] If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains Effectively you are claiming to send from [EMAIL PROTECTED] while the truth is the real sender was [EMAIL PROTECTED] - in this case it just happens that the identity behind both is same. The owners of logic.univie.ac.at are free setup any policy in SPF they want. If they think that there is no reason to protect unauthorisized use of their domain, they can choose to setup and wildcard and allow any IP in the world to send mails using logic.univie.ac.at domain. What is your problem with that setup? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: recent spam to this list
On Fri, Oct 10, 2003 at 12:21:33PM +0200, Gerfried Fuchs wrote: * Tollef Fog Heen [EMAIL PROTECTED] [2003-10-09 22:03]: (please take this off -private, don't sure where, though. Please quote me anywhere.) Same for me -- so this whole message is quoteable outside of -private. Moved to devel, where it might pester less people. I think it's a silly proposal, since it will hinder people like me who are sending all their mail from a laptop to send their mail properly. The concept of SMTP AUTH is completely new to you, is it? Sorry, these kind of objections are just as silly as you call the proposal silly. but it'll suck for mobile users in general. Mobile users are strongly encouraged to use SMTP AUTH. SMTP AUTH is no magic solution, you'd have to start routing mail by sender instead of recipient. Take myself, sharing a computer at home with somebody else who uses a completely different domain for her e-mail. Currently I simply take all mail and throw it to my current[1] internet access provider's smarthost. I would have to change the mail routing to send mail from me to smarthost A and mail from the other person to smarthost B. Even myself alone uses different domains for my mail, e.g. very rarely @debian.org. cu andreas [1] Yes, I change them.
