On Tue, Jan 27, 2009 at 01:51:48PM -0600, Barry Finkel wrote:
>> I was surprised to learn last week that RFC 2822 has been made
>> obsolete by RFC 5322, and 2821 by 5321. I think that the major
>> changes wre to clear up sections where there were differences of
>> interpretation.
and Adam McGregg
On 01/27/09 13:19, Lindsay Haisley wrote:
It is not a misconfiguration of a MTA for for the envelope sender to
be of the form "@.." as long as this is a
working address.
Agreed. I was referring to the common question on MTA support lists
along the lines of "Why is sending emails out as
'@.
On Tue, Jan 27, 2009 at 01:51:48PM -0600, Barry Finkel wrote:
> I was surprised to learn last week that RFC 2822 has been made
> obsolete by RFC 5322, and 2821 by 5321. I think that the major
> changes wre to clear up sections where there were differences of
> interpretation.
I saw the update/obs
On Tue, 2009-01-27 at 09:25 -0600, Grant Taylor wrote:
> Though I think that the MTA sending out as
> @.. is a mis-configuration on the MTA's part.
It should be noted as well that it's not the MTA's job to set the
envelope sender address, nor is there any configuration in a proper MTA
to default
>Please see Sec. 3.6 of RFC 2822 for a full discussion of various e-mail
>header fields and their proper uses and meanings, and RFC 2821 for a
>discussion of the trace fields, such as Return-Path. It is not a
>misconfiguration of a MTA for for the envelope sender to be of the form
>"@.." as long a
On Tue, 2009-01-27 at 09:25 -0600, Grant Taylor wrote:
> I can see how altering your From (depending on where you are sending to)
> could be a possibility. Though I think that the MTA sending out as
> @.. is a mis-configuration on the MTA's part.
> As far as the Sender: header, I can see that,
On 01/26/09 20:30, Stephen J. Turnbull wrote:
Sure. Anybody who uses a single host to send mail but alters their
From according to the venue (me, for example). Anybody whose MTA
identifies the envelope sender as u...@actual-host.example.com, but
whose MUA identifies them as u...@example.com i
on 1/26/09 6:09 PM, Grant Taylor said:
I meant the Return-Path with is the SMTP envelope sender.
In theory, your MTA should be putting the envelope sender address into
the "Return-Path:" header, so these two should always match.
If not, then you should talk to the vendor of your MTA softwar
Grant Taylor writes:
> About the only thing that I can think of where the From: and the
> Return-Path: might not match is a forward or some other thing like
> that. However I can't see why any one would have addresses
> forwarding in to a mailing list.
>
> Do you have such an example handy?
On 01/26/09 17:19, Mark Sapiro wrote:
About the only things that you can "normally" expect to match are
From: and envelope sender, but even there, there will be legitimate
mail in which they won't match.
I meant the Return-Path with is the SMTP envelope sender.
About the only thing that I can
Lindsay Haisley wrote:
>On Mon, 2009-01-26 at 14:34 -0700, Steve Lindemann wrote:
>> would mailman remove it from the header for
>> final delivery to the list members?
>
>Yes, absolutely. Not only in the text/plain part but in every part of a
>multipart message in which it occurs. Otherwise
Lindsay Haisley wrote:
>On Mon, 2009-01-26 at 16:49 -0600, Grant Taylor wrote:
>> Is there a way that we can require some of these things (if they exist)
>> to match each other? I.e. to require the 'from' and the 'reply-to' to
>> match?
>
>This might not be such a good idea. A "Reply-To" heade
On Mon, 2009-01-26 at 16:54 -0600, Grant Taylor wrote:
> It will be *VERY* difficult for me to spoof an SMTP envelope sender for
> Microsoft with out SPF filters (and the likes) detecting it and acting
> accordingly.
My experience with SPF is that it's not at this point widely enough
deployed so
On 01/26/09 16:51, Lindsay Haisley wrote:
It's no more difficult to spoof the From header than it is to spoof
the envelope sender address, but at least this way, if it happens
again, you'll more easily see which header got the spam through and
not have to go digging for it.
I'll agree it's al
On Mon, 2009-01-26 at 15:44 -0700, Steve Lindemann wrote:
> Thanks... I like that solution much more better 8^)
It's no more difficult to spoof the From header than it is to spoof the
envelope sender address, but at least this way, if it happens again,
you'll more easily see which header got the s
Lindsay Haisley wrote:
On Mon, 2009-01-26 at 15:26 -0700, Steve Lindemann wrote:
Thanks! Got it! They spoofed a legitimate list member on the
Return-Path:, which also showed up on the first ("From ") message header
line.
Both of these reflect the envelope sender address used in the SMTP
dial
On Mon, 2009-01-26 at 14:51 -0700, Steve Lindemann wrote:
> Rechecked the delivered message header and found the list bounces
> address in the Sender: and Return-Path: headers, but I thought that was
> normal on the delivered message.
It is, if you're looking at the _distributed_ post. This is
Mark Sapiro wrote:
All the headers of the spam post. In a default installation, if any of
From:, Reply-To: or Sender: headers or the envelope sender as
reflected in the Unix From or Return-Path: header contains a member
address, the post will be deemed from that member.
Find the spam posts in ar
On Mon, 2009-01-26 at 14:34 -0700, Steve Lindemann wrote:
> Lindsay Haisley wrote:
> > Is it possible that the list mod or admin password got out? I believe
> > than anyone can post to a moderated list by putting an "Approved:
> > " header or pseudo-header in a post.
>
> I'm on one of the lists t
Lindsay Haisley wrote:
Is it possible that the list mod or admin password got out? I believe
than anyone can post to a moderated list by putting an "Approved:
" header or pseudo-header in a post.
I'm on one of the lists that accepted the message (which is how it came
to my attention) and I ju
Is it possible that the list mod or admin password got out? I believe
than anyone can post to a moderated list by putting an "Approved:
" header or pseudo-header in a post.
On Mon, 2009-01-26 at 13:40 -0700, Steve Lindemann wrote:
> Had something strange occur early Saturday morning. A non-subsc
Had something strange occur early Saturday morning. A non-subscriber
managed to successfully post to two member only lists (and, of course,
it was spam).
The bogus sender (thelevisstoreonl...@levis.rsys1.com) is not a member
of these member only lists and is not in the accept_these_nonmembers
22 matches
Mail list logo