Re: SPF plugin ignores existing Authentication-Results

o see Authentication-Results: headers from other milter, the other milter must run before milter using SA (spamass-milter, amavisd-milter, etc) SA milter has to synthetize the Received: header it passsed with mail to SpamAssassin.  If it prepends Received: header (as expected), the Authentication-Re

Re: SPF plugin ignores existing Authentication-Results

Matus UHLAR - fantomas: this is more an issue of how milter itself operates. the milter is supposed to see e-mail as it was received from (smtp) client - even without Received: headers, just with other milters' modifications. If SpamAssassin (SA from now) has to see Authentication-Re

Re: SPF plugin ignores existing Authentication-Results

David Bürgin: > David Bürgin: > > Bother. I think I will try to modify my SpamAssassin milter, so that it > > will add a synthetic ‘internal’ Received header right after the > > Authentication-Results headers … that should trick SpamAssassin into > > recognising them a

Re: SPF plugin ignores existing Authentication-Results

Matus UHLAR - fantomas: Possible workarounds require trusting the Authentication-Results: header either via SA milter (which would add synthetized Received: header after it), or via SpamAssassin itself (trust headers added by "host" immediately after last trusted/internal "Receiv

Re: SPF plugin ignores existing Authentication-Results

Matus UHLAR - fantomas: this is more an issue of how milter itself operates. the milter is supposed to see e-mail as it was received from (smtp) client - even without Received: headers, just with other milters' modifications. If SpamAssassin (SA from now) has to see Authentication-Re

Re: SPF plugin ignores existing Authentication-Results

rom now) has to see Authentication-Results: headers from other milter, the other milter must run before milter using SA (spamass-milter, amavisd-milter, etc) SA milter has to synthetize the Received: header it passsed with mail to SpamAssassin. If it prepends Received: header (as expected), the

Re: SPF plugin ignores existing Authentication-Results

Martin Gregorie: Have you set the 'internal_networks' configuration parameter (in local.cf)? If not, try that first. Thanks, but I don’t think this helps here. I don’t know what I could add to internal_networks that would somehow change the behaviour. The problem is with how milters for SpamAss

Re: SPF plugin ignores existing Authentication-Results

On Tue, 2021-05-18 at 10:00 +0200, David Bürgin wrote: > David Bürgin: > > Bother. I think I will try to modify my SpamAssassin milter, so that > > it > > will add a synthetic ‘internal’ Received header right after the > > Authentication-Results headers … that sho

Re: SPF plugin ignores existing Authentication-Results

David Bürgin: Bother. I think I will try to modify my SpamAssassin milter, so that it will add a synthetic ‘internal’ Received header right after the Authentication-Results headers … that should trick SpamAssassin into recognising them as internal. Here’s the plan to address this in

Re: SPF plugin ignores existing Authentication-Results

SpamAssassin 3.4.4-1ubuntu1.1 on Ubuntu Server 20.04. Oh, it actually cannot work. SpamAssassin only accepts Authentication-Results that come *before* an ‘internal’ Received header (https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustedRelays). I use SpamAssassin as a milter, so the

SPF plugin ignores existing Authentication-Results

I use a separate SPF component (https://crates.io/crates/spf-milter). It conveys SPF results for both HELO and MAIL FROM identity, each in its own Authentication-Results header: Authentication-Results: mail.gluet.ch; spf=fail smtp.mailfrom=bounces.amazon.co.jp Authentication-Results

Re: Make SpamAssassin use SPF results in an Authentication-Results header?

On Wed, 4 Nov 2020 16:18:56 +0100 David Bürgin wrote: > Hello, > > as far as I understand, SpamAssassin can recognise and consume > incoming SPF results in an Authentication-Results or Received-SPF > header, so that it doesn’t have to do its own SPF evaluation. > > I’m us

Make SpamAssassin use SPF results in an Authentication-Results header?

Hello, as far as I understand, SpamAssassin can recognise and consume incoming SPF results in an Authentication-Results or Received-SPF header, so that it doesn’t have to do its own SPF evaluation. I’m using SpamAssassin in a milter setup with Postfix, and have an SPF milter that runs before

Re: Authentication-Results

Geoffrey Leach skrev den 2013-11-10 21:58: Are there any rules for analyzing Authentication-Results headers? you open a can of worms asking this :=) http://spamassassin.1065346.n5.nabble.com/Creating-new-rules-td105984.html well i still miss to see dmarc testing in sa subject is done if its

Authentication-Results

Are there any rules for analyzing Authentication-Results headers?

Re: Tarpitting (was Re: Spam harvesting using Fake Authentication)

On Mon, 19 Aug 2013, David F. Skoll wrote: On Mon, 19 Aug 2013 08:36:14 -0700 (PDT) John Hardin wrote: [...] In addition, tarpitting is at least partly intended to help *others*, by getting the attacker stuck before it moves on to the next target. OK; I guess it's just a difference in mind

Re: Tarpitting (was Re: Spam harvesting using Fake Authentication)

On Mon, 19 Aug 2013 08:36:14 -0700 (PDT) John Hardin wrote: [...] > In addition, tarpitting is at least partly intended to help *others*, > by getting the attacker stuck before it moves on to the next target. OK; I guess it's just a difference in mindset. I approach the problem with the follow

Re: Tarpitting (was Re: Spam harvesting using Fake Authentication)

On Mon, 19 Aug 2013, David F. Skoll wrote: On Mon, 19 Aug 2013 07:52:15 -0700 (PDT) John Hardin wrote: Have you considered TCP Tarpitting instead of just blocking them? Blocking them doesn't actually *punish* them. Getting their MTAs *stuck* for hours or days does. IMO, tarpitting is usele

Re: Tarpitting (was Re: Spam harvesting using Fake Authentication)

>It seems to me that greylisting and TCP tarpitting catch both sides of the >problem. Greylisting blocks junk from the single-attempt zombies, and TCP >tarpitting will catch the ones who are persistent offenders. Maybe, probably not. Modern MTAs, even the ones that are not spambots, can run hun

Re: Spam harvesting using Fake Authentication

On 8/19/2013 7:31 AM, John Hardin wrote: On Sun, 18 Aug 2013, Len Conrad wrote: Came up with a cool trick that seems to be working well after running for several months. I do the same by harvesting the IPs that fail SMTP AUTH a number of times, and then if more than a number of IPs in a Cla

Re: Tarpitting (was Re: Spam harvesting using Fake Authentication)

On Mon, 19 Aug 2013 07:52:15 -0700 (PDT) John Hardin wrote: > >> Have you considered TCP Tarpitting instead of just blocking them? > >> Blocking them doesn't actually *punish* them. Getting their MTAs > >> *stuck* for hours or days does. > > IMO, tarpitting is useless. When you have hundreds, t

Re: Tarpitting (was Re: Spam harvesting using Fake Authentication)

On Mon, 19 Aug 2013, David F. Skoll wrote: On Mon, 19 Aug 2013 07:31:33 -0700 (PDT) John Hardin wrote: Have you considered TCP Tarpitting instead of just blocking them? Blocking them doesn't actually *punish* them. Getting their MTAs *stuck* for hours or days does. IMO, tarpitting is use

Tarpitting (was Re: Spam harvesting using Fake Authentication)

On Mon, 19 Aug 2013 07:31:33 -0700 (PDT) John Hardin wrote: > Have you considered TCP Tarpitting instead of just blocking them? > Blocking them doesn't actually *punish* them. Getting their MTAs > *stuck* for hours or days does. IMO, tarpitting is useless. When you have hundreds, thousands or

Re: Spam harvesting using Fake Authentication

On Sun, 18 Aug 2013, Len Conrad wrote: Came up with a cool trick that seems to be working well after running for several months. I do the same by harvesting the IPs that fail SMTP AUTH a number of times, and then if more than a number of IPs in a ClassC, I block the entire ClassC. I do th

Re: Spam harvesting using Fake Authentication

>Came up with a cool trick that seems to be working well after running for >several months. I do the same by harvesting the IPs that fail SMTP AUTH a number of times, and then if more than a number of IPs in a ClassC, I block the entire ClassC. I don't care about the body of the msgs they AUTH

Re: Spam harvesting using Fake Authentication

authentication just to attract those who would try to hack passwords. All user password combinations are accepted. And it's working. All authenticated email is harvested as spam and the IP is blacklisted and spam is analyzed. And it helps waste hackers resources. I have a list of

Re: Spam harvesting using Fake Authentication

Hi, Came up with a cool trick that seems to be working well after running for > several months. > > I have several servers that are used for spam filtering and no > authenticated connections for sending email. However I advertise that I > have authentication just to attract those w

Spam harvesting using Fake Authentication

Came up with a cool trick that seems to be working well after running for several months. I have several servers that are used for spam filtering and no authenticated connections for sending email. However I advertise that I have authentication just to attract those who would try to hack

Re: Interesting Spam Trap Idea - Fake Authentication

On 2013-06-11 00:48, Neil Schwartzman wrote: On Jun 10, 2013, at 9:30 PM, Dave Warren > wrote: I doubt it's "a guy", but it wouldn't surprise me if the botnet that performs the dictionary attack forwards the results off to "a guy" to confirm that the account works

Re: Interesting Spam Trap Idea - Fake Authentication

On Mon, 10 Jun 2013 20:33:29 -0700 Marc Perkel wrote: > We'll - it does waste their time and resources. Not so they'd notice. The basic rule is: No matter how much computing power and bandwidth you have, the spammers have a lot more. Trying to tie up their resources is a waste of time. Regard

Re: Interesting Spam Trap Idea - Fake Authentication

On Mon, 10 Jun 2013 20:27:05 -0700 Marc Perkel wrote: > I'm not sure. I'm wondering if they use automation and maybe it's not > so smart. I don't think there is "a guy" typing passwords. Certainly not, but it's easy enough to program a password-cracker to try to detect honeypots. Regards, Davi

Re: Interesting Spam Trap Idea - Fake Authentication

On Jun 10, 2013, at 9:30 PM, Dave Warren wrote: > I doubt it's "a guy", but it wouldn't surprise me if the botnet that performs > the dictionary attack forwards the results off to "a guy" to confirm that > the account works. no, really, it's a bot. They have tens of millions of compromised a

Ang.: Interesting Spam Trap Idea - Fake Authentication

dea - Fake Authentication Datum: tis, jun 11, 2013 06:30 On 2013-06-10 20:27, Marc Perkel wrote: > I'm not sure. I'm wondering if they use automation and maybe it's not > so smart. I don't think there is "a guy" typing passwords. Perhaps only accepting the first passwor

Re: Interesting Spam Trap Idea - Fake Authentication

On 2013-06-10 20:27, Marc Perkel wrote: I'm not sure. I'm wondering if they use automation and maybe it's not so smart. I don't think there is "a guy" typing passwords. Perhaps only accepting the first password for any particular account from a single IP, and rejecting different password atte

Re: Interesting Spam Trap Idea - Fake Authentication

>One of the things I like about it is that if hackers are sending spam >into my fake server then it takes away from their efforts on real >accounts that they could hack. I'm wondering if enough of us put up fake >authentication not only can we detect spam that way but we could

Re: Interesting Spam Trap Idea - Fake Authentication

Marc Perkel skrev den 2013-06-11 05:33: We'll - it does waste their time and resources. Maybe it would be better if it failed every time just to keep them working at it. Maybe I should open pop and imap ports just to make it more inviting looking. +1 ;) as is spammers knowing using pop3 to se

Re: Interesting Spam Trap Idea - Fake Authentication

On 6/10/2013 8:38 AM, David F. Skoll wrote: On Mon, 10 Jun 2013 08:32:35 -0700 Marc Perkel wrote: I decided to implement and advertise that the server had SMTP athentication even though there was nothing to authenticate. I created an authenticator that would accept any username and password.

Re: Interesting Spam Trap Idea - Fake Authentication

On 6/10/2013 8:53 AM, David F. Skoll wrote: On Mon, 10 Jun 2013 17:49:11 +0200 John Wilcock wrote: Theoretically you could detect such confirmation messages (logically the first message from a given user,password pair) and actually deliver them, then harvest the rest! But you'd have to be rea

Re: Interesting Spam Trap Idea - Fake Authentication

David F. Skoll skrev den 2013-06-10 17:53: Also, putting on a spammer hat (NOT that I actually own one!) if the credentials "user/password" worked for me via SMTP AUTH, I would then try "user/anotherpassword" and if those *also* worked, I'd assume it was a honeypot and avoid it. i would del

Re: Interesting Spam Trap Idea - Fake Authentication

John Wilcock skrev den 2013-06-10 17:49: Theoretically you could detect such confirmation messages (logically the first message from a given user,password pair) and actually deliver them, then harvest the rest! But you'd have to be really careful not to become a spam relay in the process! mang

Re: Interesting Spam Trap Idea - Fake Authentication

Marc Perkel skrev den 2013-06-10 17:32: Thoughts? postfix recently got smtpd_relay_restrictions, wonder if it comes from that idear, its not need auth if spam is just delivered localy not needing relaying, but it will still be possible to make alias forwarding so its not relaying, just deli

Re: Interesting Spam Trap Idea - Fake Authentication

On Mon, 10 Jun 2013 17:49:11 +0200 John Wilcock wrote: > Theoretically you could detect such confirmation messages (logically > the first message from a given user,password pair) and actually > deliver them, then harvest the rest! But you'd have to be really > careful not to become a spam relay i

Re: Interesting Spam Trap Idea - Fake Authentication

Le 10/06/2013 17:38, David F. Skoll a écrit : That's an interesting honeypot. I've seen spammers crack SMTP AUTH passwords, but in most cases the first thing they do is send an email to a freemail account with a subject like: 192.168.33.55,user,passwd and if they don't get the round-tr

Re: Interesting Spam Trap Idea - Fake Authentication

On Mon, 10 Jun 2013, Marc Perkel wrote: I'm experimenting with an interesting spam trap idea. Normally I run many inbound servers as spam filters (Using Exim) with no SMTP authentication. But then I got this idea I decided to implement and advertise that the server had

Re: Interesting Spam Trap Idea - Fake Authentication

On Mon, 10 Jun 2013 08:32:35 -0700 Marc Perkel wrote: > I decided to implement and advertise that the server had SMTP > athentication even though there was nothing to authenticate. I > created an authenticator that would accept any username and password. > But it's obviously spam. Then I harvest

Interesting Spam Trap Idea - Fake Authentication

I'm experimenting with an interesting spam trap idea. Normally I run many inbound servers as spam filters (Using Exim) with no SMTP authentication. But then I got this idea I decided to implement and advertise that the server had SMTP athentication even though there was nothi

Re: Interpreting an Authentication-Results: header ?

trying to rerun the SPF and DKIM checks itself? in sa-3.3.2/Plugin/SPF.pm is still code like this: if ($hdr =~ /^received-spf:) { // parse & return } elsif ($hdr =~ /^Authentication-Results:) { // parse & return } check_spf Maybe it's simply not documented ... i think we just need

Re: Interpreting an Authentication-Results: header ?

this: if ($hdr =~ /^received-spf:) { // parse & return } elsif ($hdr =~ /^Authentication-Results:) { // parse & return } check_spf Maybe it's simply not documented ... Andreas

Re: Interpreting an Authentication-Results: header ?

* Shankar : > Unsubscribe. list-help: list-unsubscribe: List-Post: List-Id: -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebr

Re: Interpreting an Authentication-Results: header ?

> > > >Agreed. I think it would also - at the trust boundary - need a filter > before > >the DKIM/SPF verifier that adds the Authentication-Results: header. Its > job > >would be to remove any Authentication-Results: that claim to belong to > ones > >own ADMD. &g

Re: Interpreting an Authentication-Results: header ?

e >the DKIM/SPF verifier that adds the Authentication-Results: header. Its job >would be to remove any Authentication-Results: that claim to belong to ones >own ADMD. You might want to reread section 5 of RFC 5451. That's already in the A-R spec. R's, John

Re: Interpreting an Authentication-Results: header ?

default for the authid. Agreed. I think it would also - at the trust boundary - need a filter before the DKIM/SPF verifier that adds the Authentication-Results: header. Its job would be to remove any Authentication-Results: that

Re: Interpreting an Authentication-Results: header ?

>IIRC there isn't at the moment. One thought that comes to mind immediately: > >If there were it should not be enabled by default or others will try to forge >the results. It should only be enabled if a "trust boundary" > has been established. The >do

Re: Interpreting an Authentication-Results: header ?

John, * John Levine : > The Authentication-Results: header defined in RFC 5451 can describe > the SPF and DKIM status of a message. It's typically added by the > SMTP daemon as the message is received. > > Is there any way to tell spamassassin to look at the A-R header rat

Re: Interpreting an Authentication-Results: header ?

On Fri, 2013-03-29 at 00:56 +, John Levine wrote: > The Authentication-Results: header defined in RFC 5451 can describe > the SPF and DKIM status of a message. It's typically added by the > SMTP daemon as the message is received. > > Is there any way to tell spamassassi

Interpreting an Authentication-Results: header ?

The Authentication-Results: header defined in RFC 5451 can describe the SPF and DKIM status of a message. It's typically added by the SMTP daemon as the message is received. Is there any way to tell spamassassin to look at the A-R header rather than trying to rerun the SPF and DKIM c

Re: [users@httpd] Basic Auth Authentication Wonkiness with scripts or Static HTML not protected by Basic Auth accessing resources protected by Basic Auth In when using Apache & Internet Explorer

re: http://httpd.apache.org/docs/2.2/howto/auth.html#possibleproblems I just wanted to point the following: Because of the way that Basic authentication is specified, your username and password must be verified every time you request a document from the server. This is even if you&#x

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

This is now bug 5235 http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5235

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

On Dec 5, 2006, at 4:17 PM, Daryl C. W. O'Shea wrote: Jo Rhett wrote: While you are fixing bugs related to authentication, any chance you'll fix the SPF plugin to skip checks on authenticated delivery? Or have an option to enable this behavior? Or do you want a patch from me?

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Jo Rhett wrote: On Dec 5, 2006, at 2:02 AM, David B Funk wrote: It still should not matter. So long as the client can authenticate to the server's statisfaction, SA should honor its decision regardless of how bogus the HELO or client's DNS entrys look. That's your argument. That may not ha

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Jo Rhett wrote: While you are fixing bugs related to authentication, any chance you'll fix the SPF plugin to skip checks on authenticated delivery? Or have an option to enable this behavior? Or do you want a patch from me? It'll take me a lot longer than you, since I'll s

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Mark Martinec wrote: Not sure if the following one is relevant, but it just fell into my hands: Received: from 10.235.209.117 (SquirrelMail authenticated user sername) by xxx.ijs.si with HTTP; Tue, 5 Dec 2006 15:31:13 +0100 (CET) Thanks Mark. Anything with a with

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

> SMTP-AUTH: > Received: from [128.114.2.223] (account [EMAIL PROTECTED] HELO > [128.114.2.223]) by silver.ucsc.edu (CommuniGate Pro SMTP 4.3.7) >with ESMTPSA id 88402416 for [EMAIL PROTECTED]; Mon, 04 Dec 2006 13:15:07 > -0800 > > Webmail: > Received: from [128.114.2.223] (account [EMAIL PROT

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

While you are fixing bugs related to authentication, any chance you'll fix the SPF plugin to skip checks on authenticated delivery? Or have an option to enable this behavior? Or do you want a patch from me? It'll take me a lot longer than you, since I'll spend hours just t

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Jo Rhett wrote: Do you know why the SMTP authenticating server was forging the HELO name? Normal mail clients will give their IP address, right? And the "may be forged" only appears if they gave a full name and resolution succeeded *and* none of the addresses returned matched the helo na

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

On Dec 5, 2006, at 2:02 AM, David B Funk wrote: Jo you are mistaken. Sendmail adds the "(may be forged)" comment when the client's IP rDNS and DNS don't match, it has -nothing- to do with the HELO name. RTFC(...code) If the hello is numeric or non a domain name, the "may be for

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

t at making > it clearer yourself. OK, but it would be better if you showed the full workaround (i.e. add a line with "score LOCAL_AUTH_RCVD -10.0"). >> 2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Sendmail's >> authentication >> under some circumstanc

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Daryl C. W. O'Shea wrote: John Rudd wrote: Though, CommuniGate Pro's authenticated received header looks like this: from [$ipaddr] (acccount $account HELO $helostring) by $host (CommuniGate Pro So, you could match that with: /^from \[\S+\] \(account [EMAIL PROTECTED] .*\) by \S+ \(CommuniG

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

John Rudd wrote: Daryl C. W. O'Shea wrote: Could you provide me with some sample headers so that I can add these? I can't add them without regression tests. SMTP-AUTH: Received: from [128.114.2.223] (account [EMAIL PROTECTED] HELO [128.114.2.223]) by silver.ucsc.edu (CommuniGate Pro

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

John Rudd wrote: Daryl C. W. O'Shea wrote: John Rudd wrote: Though, CommuniGate Pro's authenticated received header looks like this: from [$ipaddr] (acccount $account HELO $helostring) by $host (CommuniGate Pro So, you could match that with: /^from \[\S+\] \(account [EMAIL PROTECTED] .*\)

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Daryl C. W. O'Shea wrote: John Rudd wrote: Daryl C. W. O'Shea wrote: John Rudd wrote: Though, CommuniGate Pro's authenticated received header looks like this: from [$ipaddr] (acccount $account HELO $helostring) by $host (CommuniGate Pro So, you could match that with: /^from \[\S+\] \(ac

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Jo Rhett wrote: Do you know why the SMTP authenticating server was forging the HELO name? Normal mail clients will give their IP address, right? And the "may be forged" only appears if they gave a full name and resolution succeeded *and* none of the addresses returned matched the helo name.

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

David B Funk wrote: On Tue, 5 Dec 2006, Jo Rhett wrote: In short, this may have been a deliberate choice to prevent a match on hosts with forged helo names. It would make sense. Jo you are mistaken. Sendmail adds the "(may be forged)" comment when the client's IP rDNS and DNS don't match, i

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

John Rudd wrote: Though, CommuniGate Pro's authenticated received header looks like this: from [$ipaddr] (acccount $account HELO $helostring) by $host (CommuniGate Pro So, you could match that with: /^from \[\S+\] \(account [EMAIL PROTECTED] .*\) by \S+ \(CommuniGate Pro/ Cool, I don't th

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

d the problem. As I said yesterday, I updated the wiki page to hopefully make this clear. If it's still somehow not clear that it's only a workaround please let me know, or take a shot at making it clearer yourself. 2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Send

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

On Tue, 5 Dec 2006, Jo Rhett wrote: > René Berber wrote: > > It's the same one I posted before: > > > > Received: from MARISELA (dsl-189-149-70-163.prod-infinitum.com.mx > > [189.149.70.163] (may be forged)) > > (authenticated bits=0) > > by mail.legosoft.com.mx (8.13.8/8.13.8) with ESMTP

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

; part. You say "normal clients", well this client is Microsoft Outlook (Office 200x edition), I don't see anything abnormal in what it is doing. Giving the IP address is probably useless if they are, most of the time, inside a private network (no name resolution at all). The tes

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

René Berber wrote: Jo Rhett wrote: René Berber wrote: The change I made works on a test from someone that was on vacation and sending a message (to me) using his ISP account, the header includes a lot of extra text with the usual dynamic IP stuff and "may be forged" and there was no way it wou

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Jo Rhett wrote: > René Berber wrote: >> >> The change I made works on a test from someone that was on vacation and >> sending >> a message (to me) using his ISP account, the header includes a lot of extra >> text >> with the usual dynamic IP stuff and "may be forged" and there was no way it >> w

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

René Berber wrote: Or send me a copy of your recieved line and I'll do the patch for you. The change I made works on a test from someone that was on vacation and sending a message (to me) using his ISP account, the header includes a lot of extra text with the usual dynamic IP stuff and "may be

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

l line. With my change, there is a match. It is probable that other, fixed, IPs can be matched by that original line, but I haven't even look at them since the sendmail configuration I'm using is some fixed IPs defined in relay-domains and access db, those don't need to use authentication, ever

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

René Berber wrote: Jo Rhett wrote: René Berber wrote: If I change Received.pm, line 414, like this: # Sendmail, MDaemon, some webmail servers, and others - elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) { + elsif (/^from .*?(.*?authenticated.*?\).*? by/) { This can't b

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Jo Rhett wrote: > René Berber wrote: >> If I change Received.pm, line 414, like this: >> >> # Sendmail, MDaemon, some webmail servers, and others >> - elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) { >> + elsif (/^from .*?(.*?authenticated.*?\).*? by/) { > > This can't be r

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Sorry, in my reply I meant to point out that the original line was working properly for me (Sendmail environment) but that the line working did not solve my problem. John Rudd wrote: Jo Rhett wrote: René Berber wrote: If I change Received.pm, line 414, like this: # Sendmail, MDaemon, some

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

Jo Rhett wrote: René Berber wrote: If I change Received.pm, line 414, like this: # Sendmail, MDaemon, some webmail servers, and others - elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) { + elsif (/^from .*?(.*?authenticated.*?\).*? by/) { This can't be right. You have m

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

aying two things: 1) LOCAL_AUTH_RCVD doesn't do anything useful, just to clarify what happened to the original subject. 2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Sendmail's authentication under some circumstances. I assume that it does recognize it for other messages, even if I ha

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

René Berber wrote: If I change Received.pm, line 414, like this: # Sendmail, MDaemon, some webmail servers, and others - elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) { + elsif (/^from .*?(.*?authenticated.*?\).*? by/) { This can't be right. You have mismatched parens.

Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)

o things: 1) LOCAL_AUTH_RCVD doesn't do anything useful, just to clarify what happened to the original subject. 2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Sendmail's authentication under some circumstances. I assume that it does recognize it for other messages, even if I

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

> Are there any SA methods that allow verification of the ‘sender’ of an email ? > > I am aware of SPF which can confirm that a host at ip address x.x.x.x is > authorized to send mail as from domain “A”, but how about a means to > confirm that [EMAIL PROTECTED] actually is a real user before

RE: source SENDER authentication ? (as opposed to SPF HOST authentication)

On Wed, 30 Aug 2006, SM wrote: > At 10:55 30-08-2006, Michael Grey wrote: > >I like Michel Vaillancourt's idea - if it has to be done. > > There are milters and MTAs that can do that. It's not a good idea as > it can cause a denial of service. Also you risk getting blacklisted. When you run one

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

On Thu, 31 Aug 2006, Benny Pedersen wrote: > On Wed, August 30, 2006 19:37, Michel Vaillancourt wrote: > > to carve it... you actually open an SMTP conversation with > > ... trap that "5xx" return, and you know its a bogus sender. > > The plug-in adds 2 points to the score. > > Get a "25

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

Benny Pedersen writes: > On Wed, August 30, 2006 19:44, Justin Mason wrote: > > list -- as the forged source of the spam. The end result for us end > > users, is a massive increase in "spam blowback", which is what we've > > seen since those MTAs implemented it. :( > > spf solves that Well, it

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

On Wed, August 30, 2006 19:44, Justin Mason wrote: > list -- as the forged source of the spam. The end result for us end > users, is a massive increase in "spam blowback", which is what we've > seen since those MTAs implemented it. :( spf solves that -- "This message was sent using 100% recycl

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

On Wed, August 30, 2006 19:37, Michel Vaillancourt wrote: > to carve it... you actually open an SMTP conversation with > ... trap that "5xx" return, and you know its a bogus sender. > The plug-in adds 2 points to the score. > Get a "250 Ok" back, and you are likely "safe"... score 0.

RE: source SENDER authentication ? (as opposed to SPF HOST authentication)

At 10:55 30-08-2006, Michael Grey wrote: I like Michel Vaillancourt's idea - if it has to be done. There are milters and MTAs that can do that. It's not a good idea as it can cause a denial of service. Regards, -sm

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

On Wed, Aug 30, 2006 at 01:37:37PM -0400, Michel Vaillancourt wrote: > > The short answer is that there's no way to do that in general, regardless > > of SA, so no. > > There is a way to do it, but someone more skilled at PERL than I would > have to carve it... you actually open an SMTP co

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

On 30-Aug-06, at 1:44 PM, Justin Mason wrote: Gino Cerullo writes: part 1.2 text/plain1027 On 30-Aug-06, at 1:10 PM, Michael Grey wrote: Are there any SA methods that allow verification of the ‘sender’ of an email ? I am aware of SPF which can confirm that a host at ip addr

RE: source SENDER authentication ? (as opposed to SPF HOST authentication)

ack to this question. Michael Grey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 10:44 AM To: Gino Cerullo Cc: users@spamassassin.apache.org Subject: Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

Gino Cerullo writes: > part 1.2 text/plain1027 > On 30-Aug-06, at 1:10 PM, Michael Grey wrote: > > > Are there any SA methods that allow verification of the ‘sender’ of > > an email ? > > > > I am aware of SPF which can confirm that a host at ip address > > x.x.x.x is author

Re: source SENDER authentication ? (as opposed to SPF HOST authentication)

Theo Van Dinter wrote: > On Wed, Aug 30, 2006 at 10:10:00AM -0700, Michael Grey wrote: >> I am aware of SPF which can confirm that a host at ip address x.x.x.x is >> authorized to send mail as from domain "A", but how about a means to confirm >> that '[EMAIL PROTECTED]' actually is a real user befo

  1   2   >