gmane.mail.spam.spf.discuss

Re: SPF Mail Summary Report

Alessandro Vesely — 2012-05-23T16:28:13


The first idea looks the best one, IMHO.

Re: SPF Mail Summary Report

Larry Smith — 2012-05-23T01:21:01

Actually I find the reports "nice" in the sense that often I don't pay
a lot of attention to a particular list, and the report lets me know I
did not miss anything, just not much being said...

Re: SPF Mail Summary Report

Scott Kitterman — 2012-05-22T22:34:34

Thanks Hector.

I think it would be nice if you could add a volume threshold for the report 
(maybe 5?).

Scott K

On Tuesday, May 22, 2012 06:12:46 PM you wrote:

Re: SPF Mail Summary Report

HECTOR SANTOS — 2012-05-22T22:12:46

Its been used for over 16 years. Earlier in other support forums, like 
ours, the Borland forums, Microsoft forums and used for these SPF 
forums since its near inception.  The IETF list has a report. And BTW, 
the SPF list had one too before ours. Its very odd you are the first 
to complain to about it.   Its been on automatic mode for years.  A 
few years back disabled for some un-recalled reason (I think computers 
were moved around) and was asked by Scott Kitterman to enable it 
again.   Sure, its useless when the volume is near zero. That wasn't 
the case in years past and it did help in some feedback items.

I will note that its probably a good idea to add logic to skip posting 
when mail is zero for the week or extend it to month or perhaps 
trigger it at some X total threshold, all of which is "TIME" on my part.

Don't let it bother you.   But if Mr. Scott Kitterman wants them off, 
hey, its no sweat off my back.  Just send me an email Scott.

Re: SPF Mail Summary Report

Scott Kitterman — 2012-05-22T16:53:55

They aren't generated by the list system.  They are posted by Hector Santos.

When spf-help was a lot higher volume, they were useful for keeping track of 
which help requests had been responded to.  I agree they are less useful now 
that the list volumes are low.

Scott K

Re: SPF Mail Summary Report

Ian Eiloart — 2012-05-22T16:27:51


Ok, let me make a polite request that the posting of traffic reports is switched off. 

1) They're off-topic
2) This is the only list that I subscribe to which posts its own traffic reports
3) They're not useful to subscribers, who can count the posts if they need to know the traffic.

Re: SPF Mail Summary Report

Benny Pedersen — 2012-05-22T11:26:33

Den 2012-05-22 13:11, Ian Eiloart skrev:



is there a way to stop recieving this complains more then once ? :))

and origin poster posts copyrighted matrial, hmp

Re: SPF Mail Summary Report

G.W. Haywood — 2012-05-22T11:18:21

Hi there,

On Tue, 22 May 2012, Ian Eiloart wrote:


Well you *are* the postmaster.  Procmail rule?

--

73,
Ged.

Re: SPF Mail Summary Report

Ian Eiloart — 2012-05-22T11:11:16

On 21 May 2012, at 18:04, <spf-discuss< at >winserver.com>
 <spf-discuss< at >winserver.com> wrote:


Is there a way to stop getting these reports. This one says the list has had no traffic, so the traffic seems to consist entirely of traffic reports.

SPF Mail Summary Report

2012-05-21T17:04:31

                    iMail News Gateway Server v3.2                    
          (c) Copyright 1996-2012 Santronics Software, Inc.           

                        Mail Forum Statistics                         
                Date Range : 21 May 2012 - 21 May 2012
                Report Date: 21 May 2012

----------------------------------------------------------------------
Total Summary:
----------------------------------------------------------------------

Total Forums          : 2
Total Messages        : 0
Total Participants    : 0
Total Vendor Postings : 0
Total Mail/No Replies : 0  (0%)
          6+ Days Old : 0    4+ Days Old: 0
          2+ Days Old : 0    1 Day Old  : 0

----------------------------------------------------------------------
Forum Summary: spf-discuss
----------------------------------------------------------------------

No Messages Posted

----------------------------------------------------------------------
Forum Summary: spf-help
--------------------------------------------

SPF Mail Summary Report

2012-05-12T04:00:04

                    iMail News Gateway Server v3.2                    
          (c) Copyright 1996-2012 Santronics Software, Inc.           

                        Mail Forum Statistics                         
                Date Range : 28 Apr 2012 - 10 May 2012
                Report Date: 12 May 2012

----------------------------------------------------------------------
Total Summary:
----------------------------------------------------------------------

Total Forums          : 2
Total Messages        : 34
Total Participants    : 10
Total Vendor Postings : 0
Total Mail/No Replies : 4  (11%)
          6+ Days Old : 3    4+ Days Old: 1
          2+ Days Old : 0    1 Day Old  : 0
Busiest Posting Hour  : 7am  (3 msgs)
Busiest Posting Day   : Wednesday  (9 msgs)

+-[ Hourly Posting Pattern ]----------------------+
|               *   *   *   * * *     *           |
|               *   *   *   * * *     *           |
|               *   *   *   * * *     *           |
|               *   *   *   * * *

Re: SPF and bouncing

alan — 2012-05-09T17:32:09

well then be assured they will have verp aware sender whitelists if they use such
(or they will fail to receive a significant amount of mail and thus be unused) 
(greylisting is a totally different technology and only deals with ips/and retrys)


or how bout just accept them and realize that no one is using <> to target you (or anyone else)
(verp is only suggested as a fix IF incoming forged <> becomes a burden)


how about as i suggested you dont try and usurp spf for some sort of verp decode protocol
(as said current batv/verp implementations are largely db based and non-trivially reversed)
but instead write/create or convince someone else who equally believes this is useful to write a separate protocol for this
if such a protocol existed then convince batv/verp users to start to use reversible verp

adding such a second protocol (without any thought as to syntax and the myriad ways a decode 'key/algorithim' could be expressed to spf seems like a futile and non-usefull proposal)

as spf provides to reciev

Re: SPF and bouncing

Michael Deutschmann — 2012-05-09T01:24:21

I'm actually more concerned about the outgoing side of the equation.  I
want to keep it easy for other people to whitelist and greylist *me*.

To that end, assuming no reform possible in any protocol, I'd rather be
"RFC-ignorant" and reject <>, than use VERP and tangle up other people's
sorting of my (non-bounce) mail.

But if a standard SPF VERP modifier was added, and there were signs that
greylist and whitelist using recipient sites were listening for it, then
my scales might tip away from rejecting <> and towards VERP....


It doesn't have to disappear into the void.  The proper way to handle it
is to declare that for handoffs from MX to internal mail store, there is
no such thing as a permanent mail failure.  Smarthosts react to a 5xx or
prolonged 4xx by generating a bounce (they can avoid backscatter with
AUTH), but the procedure for an MX should be to place the failed message
in a special hold queue, only flushed by explicit admin action.

When such a 5xx occurs, the MX automatically sets a flag to s

Re: SPF and bouncing

alan — 2012-05-07T22:37:08

ok so basically your wanting to add stuff to spf because you want an easier way to do goldlisting
(seems to be the crux here)
so your assuming anyone wanting to talk to your goldlisting implementation will
choose to use your new spf (if they use batv/verp
care to pass your filters

both i think are unlikely, better to design (like the rest of us do) a system that works with ALL current mailers, but works better/faster and with less chance of false positive on those that adopt spf/csv/dkim/etc/etc.

At 13:30 07/05/2012  Monday, Michael Deutschmann wrote:

if your gold listing you have no choice, you cant 'demand' that 'large-isp-using-batv' start adopting your 'fork' or extension to spf, simply put like spfv1 most just wont (many havn't yet adopted the simple current spf)


not spf's issue, spf has validated it came from the right ip's to be non-forged (job done)

your goldlisting and resource consumption of same is not spfs issue
(you have to let it goto data to accept from [for example yahoo] as you can onl

Re: SPF and bouncing

Michael Deutschmann — 2012-05-07T12:30:17

I wouldn't quite call whitelisting mailinglists a solved problem yet.  I
do it, but it's a hack that occasionally fails.  The key problem is that
for many mailing lists, including this one, the MAIL FROM: domain of the
distributed messages ("jeeves.archive.listbox.com") is not the same as
that of the submission address ("listbox.com").  The former sometimes
changes abruptly (this list was "v2.listbox.com" before 2007).


That lets too much stuff through to DATA.

True, an expert user with access to logs can recognize VERP and manually
tell his server to demangle the addresses coming from that site.  But I
want to aim higher and make whitelisting work for more casual users, by
making the demangling instructions *public*.


You're attacking the wrong prong of my fork here.  I'm discussing a
proposal to but a flag in SPF records advertising that VERP is in use and
a defined way to decode it.   Thus allowing the recipient to obtain the
whitelist lookup key without going to DATA.

(The fork is because we cannot

Re: SPF and bouncing

Michael Deutschmann — 2012-05-07T11:41:45

Null-mailfrom traffic other than DSNs is insignificant.  IMAO, it's ok to
break it.


Not if you need to pass a goldlist at the same time.

If the spammer uses a MAIL FROM within a domain he fully controls, he can
pass SPF with flying colors, but gets 5xxed anyway because the goldlist
has never heard of him.

If he uses the MAIL FROM of an actual correspondent of the victim, he
passes the goldlist but now cannot cheese past SPF.

---- Michael Deutschmann <michael< at >talamasca.ocis.net>

Re: SPF and bouncing

Alessandro Vesely — 2012-05-07T11:17:15

In any case, address literals are a limit for evaluating HELO.


You seem to imply that messages bearing a null-mailfrom must be
bounces.  Actually, it is the opposite way around: bounces must bear a
null-mailfrom.

BTW, during the weekend I run three tests on different samples of
about 25K domains each, counting how many domains reject a "bad"
sender but accept a good one upon a RSET.  Reject/accept percentages
result as follows:

reject-on-fail a:     1.11%
reject-on-fail b:     1.21%
reject-null-mailfrom: 0.24%


It is equally trivial to engineer such a pass using MFROM.

You have a point there, though.  The helo identity is not a 1st class
citizen of any reputation system.  Even if it were mail.gmail.com, it
would not be reliable to make guesses at zone cuts.  Moreover, as Alan
points out, many helo names are unrelated to the branded domain.  For
the tests above, I found about 50% unique MXes/domain;
thus, if outgoing mail flows symmetrically, an helo identity serves
about two domains, on average.

Re: SPF and bouncing

alan — 2012-05-06T03:59:08

last post this is just nothing to do with spf

At 02:17 06/05/2012  Sunday, Michael Deutschmann wrote:

obviously its not spf's job


that would be a dumb algorithim, and would fail for 99% of all mail
a chance of working one would be
when sending mail from fred< at >yourdomain cache domains of all mx's(listed for recipient) (in this case xxxx.google.com)
then accept <> from helo's within those domains (if not spf fail) (spf non-users are allowed to legit bounce too) if going to fred< at >yourdomain

(better would be to parse the body and see if its a legit ndr (as it should normally include the to/from/ and likely your message-id, there are only about 20-70 MTAs in common use and validating legit bounce pattern from most wouldn't be rocket science)

as anyone at anydomain has their mail go via theirprovidersdomain (both in and out)
(those who point mxX.theirdomain at their providers IP break tls so should learn better and point their mxs at the name their provider uses in helo.theirprovidersdomain)

this is why there

Re: SPF and bouncing

Michael Deutschmann — 2012-05-06T01:17:19

No, it has nothing to do with [] in addresses.

The problem is that the HELO domain is of no use in determining if an
incoming MAIL FROM: <> has anything to do with a message you actually
sent in the past month.

gmail.com's MXes and smarthosts are kept within the domain of their
corporate sponsor, google.com.  If gmail.com were ever to issue a bounce,
it would likely bear a HELO ending in .google.com.  So a naive algorithm
that said "let a purported bounce through if the HELO is SPF-approved and
is equal to or a subdomain of any domain we have mailed to in the past
month" would fail badly for at least one major site.

Drop the "is equal to or a subdomain" requirement, and any spammer who
wants to exploit the <> loophole will do so using a HELO domain that he
fully owns.  Then it's trivial for him to engineer a genuine SPF Pass.

Thus, for spam control purposes it is best to ignore the HELO (aside from
certain idiot filters), and treat all <> mail as effectively SPF-neutral.

---- Michael Deutschmann <micha

Re: SPF and bouncing

alan — 2012-05-05T13:20:37

helo authentication can be a great idiot filter (not spamsign but like ptr>A>ip FQRDNS check can be great reason to reject)
as long as whitelisting is possible for some idiots

non-pass if spf exists is pretty much a guarenteed reject for most of my users (except for facebook, as most of their servers have broken helo spf or broken helo A records)


not immediate reject (just like connecting from blacklisted IP, the reject happens at RCPT time the reject message says why)
its not mis-configuration its sanity checking, and a good way to filter both bots and mailservers that a setup badly (thus unlikely to be sending anything usefull/wanted)
as mail has gotten to the rcpt stage the user can see the mail-from helo-id ip and fqrdns in their reject log and whitelist if neccissary, more-often they will just point the far side at our 'how you should setup your mta' guide and let them fix the issue that caused the reject, rather than turning off the checks and maintaining their own whitelist. 

when you give users

Re: SPF and bouncing

Alessandro Vesely — 2012-05-05T11:08:00

You must mean address literals, which are mostly used by MUAs AFAIK.
Addresses like <postmaster< at >[66.39.2.7]> most likely don't work.
With that exception, the domain of an MFROM can be anything that a
HELO name can be.

At any rate, arranging for an SPF HELO /neutral/ is trivial.  A HELO
/pass/ is as reliable as a DKIM pass: both of them authenticate a
relay by referring to the corresponding DNS zone.


I agree that HELO checking is somewhat ambiguous by design, since it
is optional, but its result can neither cause rejection[*] nor be
merged with the result of the mandatory check.  However, pruning it
doesn't seem to yield grand simplifications either.

[*] HELO checking won't deliver a fail, unless misconfigured.  That
is, anyone can say "HELO hostnotfound.google.com" and get away with it.