VERP + multi-RCPT
Gerrit Pape
it seems that there is some confusion about the meanings of VERP_README in
postfix snapshot-20010808. So Matthias Andree strongly objects against my
words
"It is not possible for a mailing list server delivering to standard smtp
server to perform VERP and multi-RCPT while handling the mailinglist."
[A standard smtp server is any kind of mta talking smtp. Matthias noticed
that standard smtp server must not be postfix snapshot-20010808.]
with pointing me to that VERP_README. And, as suggested, also postfix
cannot do the magic.
This is my understanding of VERP_README from snapshot-20010808:
postfix supports VERP style delivery in two cases:
1. local injection with the postfix sendmail binary
2. when receiving mail through smtp
I took a look into the postfix sources the first time, but it seems that
in both cases, when VERP style delivery is requested, the messages will be
marked as REC_TYPE_VERP. qmgr_message.c then will not bundle this message
with others (qmgr_message_read(): row 308, qmgr_message_assign(): row 727)
and single-rcpt will be performed.
It is an advantage anyway, but not for saving bandwidth by doing multi-rcpt
on VERPed mailinglists.
I still believe, it is not possible with today's smtp specification. Please
correct me if I am wrong.
Is XVERB a proposal? Are there any known smtp clients testing for XVERP and
using it? postfix snapshot-20010808 itself seems only to have this in the
smtpd code, but not in the smtp (client) code, so by now it is not testing
for XVERP when delivering, even if there would be postfixes with XVERP
support on both sides, XVERP would not be used, IMHO.
One could think, it could lead into performance disadvantages in queue
handling, having more and more code testing if multi-rcpt VERP style
delivery is possible and performing multi rcpt (I do not claim that to be
true).
Regards, Gerrit.
--
pa...@innominate.com
innominate AG
tel: +49.30.308806-0 fax: -77 http://www.innominate.com
-
To unsubscribe, send mail to majo...@postfix.org with content
(not subject): unsubscribe postfix-users
Matthias Andree
> it seems that there is some confusion about the meanings of VERP_README in
> postfix snapshot-20010808. So Matthias Andree strongly objects against my
> words
> "It is not possible for a mailing list server delivering to standard smtp
> server to perform VERP and multi-RCPT while handling the mailinglist."
>
> [A standard smtp server is any kind of mta talking smtp. Matthias noticed
> that standard smtp server must not be postfix snapshot-20010808.]
I don't grasp your note in square brackets. I said XVERP is a feature
that Postfix offers since the July 2001 snapshots, not "any kind of mta"
would do that.
Gerrit, there is some misunderstanding here. Of course, Xanything is
a non-standard, proprietary extension in ESMTP and will never be
standardized with the X prefix (XVERP MAIL command attribute).
And of course, you can't do VERP+MultiRCPT currently to "any" MTA.
However, the mailing list software offloads its work to the *local* MTA,
not to remote MTAs (usually; that may be different for Windows MUAs that
have list management facilities), so it's a matter of what the *local*
MTA makes of it. I have also failed to find code in smtp (client) that
recognizes the other side to be a Postfix box that talks XVERP, but I'd
consider it a very useful feature.
My imagination is that you send a Multi-RCPT VERP'ed mail to your local
MTA, and that looks for you if it can send VERP'ed mail to the recipient
MX/domain or not.
> It is an advantage anyway, but not for saving bandwidth by doing multi-rcpt
> on VERPed mailinglists.
Not yet, indeed, but I didn't claim otherwise. There is currently no
internet draft that the ietf search engine would show when looking for
VERP.
> One could think, it could lead into performance disadvantages in queue
> handling, having more and more code testing if multi-rcpt VERP style
> delivery is possible and performing multi rcpt (I do not claim that to be
> true).
Well, the test would happen once, when you parse the ESMTP extensions a
server speaks, in the reply to your EHLO command, smtp would then need
to handle the "That domain doesn't have XVERP, let's do single-RCPT
delivery" case, qmgr wouldn't need to break apart that code.
However, I haven't thought about the impact that this would have for
UUCP.
Matthias Andree
> Well, the test would happen once, when you parse the ESMTP extensions a
> server speaks, in the reply to your EHLO command, smtp would then need
smtp == Postfix' smtp client
> to handle the "That domain doesn't have XVERP, let's do single-RCPT
> delivery" case, qmgr wouldn't need to break apart that code.
replace "code" by "mail for each of its recipients".
Sorry.
--
Matthias Andree
Gerrit Pape
> On Mon, 27 Aug 2001, Gerrit Pape wrote:
>
> > it seems that there is some confusion about the meanings of VERP_README in
> > postfix snapshot-20010808. So Matthias Andree strongly objects against my
> > words
> > "It is not possible for a mailing list server delivering to standard smtp
> > server to perform VERP and multi-RCPT while handling the mailinglist."
> >
> > [A standard smtp server is any kind of mta talking smtp. Matthias noticed
> > that standard smtp server must not be postfix snapshot-20010808.]
>
> I don't grasp your note in square brackets. I said XVERP is a feature
Come on, this is ridiculous. The former? I do not believe, if so, just
delete it.
The latter?
I told you in unmistakable international notation
'"standard smtp server" != postfix snapshot-20010808'
and explicitly asked you to catch that.
Your followup quoted this and told me to take a night of sleep, clean my
eyes and think again, umm, I took a weekend.
You just again scramble my words or just miss to understand them, and
publically claim (flame) them to be false like you did in
http://groups.yahoo.com/group/postfix-users/message/40628
(<20010822190241.A2259@emma1.>). Sorry, couldn't resist.
Gerrit.
--
pa...@innominate.com
innominate AG
tel: +49.30.308806-0 fax: -77 http://www.innominate.com
Matthias Andree
> The latter?
> I told you in unmistakable international notation
> '"standard smtp server" != postfix snapshot-20010808'
> and explicitly asked you to catch that.
Gerrit, I'm well aware of this. We're talking about different things.
You're talking about a list software that loads its mail off to a
standard smtp server, I'm talking about a list software that loads its
mail off to a local recent Postfix snapshot that then delivers to
standard "any" SMTP servers.
> You just again scramble my words or just miss to understand them, and
> publically claim (flame) them to be false like you did in
> http://groups.yahoo.com/group/postfix-users/message/40628
> (<20010822190241.A2259@emma1.>). Sorry, couldn't resist.
Keep calm, there is no scrambling, we're starting off from different
assumptions. That's the cause of the confusion we're seeing.
(And that's why I deliberately send to the list again, in spite of what
Mail-Followup-To: suggests.)
Let's hope this clears the mess.
Wietse Venema
adopt pending the deployment of a better solution, and at the same
time it slows down deployment of that better solution (*).
In an imaginary world, VERP would be standardized, and each SMTP
server would advertise if it does/does not support VERP. A sending
MTA could then make the decision to do VERP expansion itself (the
sending MTA would send messages with one recipient) or leaving it
up to the receiving MTA to do the VERP expansion instead (the
sending MTA would send one message with multiple recipients).
I'm not aware of an effort to standardize VERP. I see more benefit
in the standardization of non-delivery notifications.
Wietse
(*) In case people wonder what the heck Wietse is hinting at this
time: VERP is a substitute for machine-parsable bounce messages as
per RFC 1894; sending one-recipient-at-a-time email is a workaround
for protocol latencies that are more preferably fixed with SMTP
command pipelining; and NAT is a network addressing technique that
makes the deployment of IPV6/IPSEC a lot more difficult.
Matthias Andree
> (*) In case people wonder what the heck Wietse is hinting at this
> time: VERP is a substitute for machine-parsable bounce messages as
> per RFC 1894;
As long as major sites still run software that rejects mail that HAS
RFC-2822 conformant From: lines, violating RFC 822/2822 (choose either
one) and 1123, and as long as DJB's qmail is still around, you don't
seriously expect RFC-1894 machine-readable bounce messages from anyone.
Makes me wonder why Dan has deployed "machine-parseable" FTP LIST format
("EPLF", soon to be superseded by MPLF, an actual format) in his
publicfile package, but not "machine-parseable" bounce messages in
qmail. Seems he doesn't value bounce message contents either, looking at
the documentation that accompanies qmail (they're not crashproof).
--
Matthias Andree
begin dont_click_this_virus.exe
end
Site of the day: http://piology.org/ILOVEYOU-Signature-FAQ.html